I read this
"
It used to be that Android would use a single pass to process
RelativeLayout-defined rules. That meant you could not reference a widget
(e.g., via android:layout_above) until it had been declared in the XML. This
made defining some layouts a bit complicated. Starting in Android 1.6,
Android uses two passes to process the rules, so you can now safely have
forward references to as-yet-undefined widgets.
"
I do not know what is the problem maybe is eclipse problem, but even I use 2.3 I still have problems when I reference some view that is not declared jet so for me it seems like android doesn't uses two passes to process the rules for relative layout.
note: I always use #+id/widget_name when I declare the widget and #id/widget_name when I reference that widget from other widget. I have noticed that I can use #+id/widget_name even when I just want to reference that widget. I guess that is wrong but why sometimes is works without any complaints ? In my opinion one widget should be allowed to be declared only ones...
My questions is is really android uses two passes ? and I need some guidelines (best practices) for working with relative layouts
I am little confused about how this relative layout parings are made, so any explanations are welcomed
Thanks
#+id/name creates a new id, if it doesn't already exist. #id/name references an existing id, and will never create one.
I'm not sure if you can use #id/name before #+id/name in the same file. If not, I can think of two workarounds:
Always use #+id/name.
Define all id's in the ids.xml file, and always use #id/name.
This is general information on how Android draw views.
I think that Android passes twice through all the view, but it doesn't pass through each single view once. So if you have a reference from one xml to another it will always work fine, but if you have references inside a single xml you must be carefull to order the elements in the xml correctly. For example, I have view1 and view2 in my RelativeLayout. If I want to refer to view2 from view1 I must declare view2 before view1.
Related
I realize that I can create a subclass of UIButton to add custom properties:
class myButton: UIButton {
var viewBounds : CGRect = .zero
...
}
However, at this moment I only need each button to store an Int, I am not using storyboards, and a lot of postings say that it's alright to use the tag property.
My question is, is this actually safe? Given possible future changes. etc. etc.? "Many postings" is not the same as an official answer, which I can't seem to find an answer to in the official documentation.
It depends on what you're looking to use the tag property for. From the UIView.tag docs, which you have likely seen:
An integer that you can use to identify view objects in your application.
</snip>
You can set the value of this tag and use that value to identify the view later.
The purpose of tag is to be an arbitrary user-settable property that you can use to differentiate between different views of the same type when you don't otherwise have a named reference to them.
UIKit itself will never set tag because the property is meant to be set by you, the app developer; however, that doesn't mean that some 3rd-party framework you're using is guaranteed not to stomp on tag values. Because tag lives in a "global" namespace of sorts (all code has equal access/knowledge to tag, unlike a property you might add yourself), different people might try to use tag for different things.
If you're creating view objects yourself, and managing the view hierarchy directly, then it's relatively safe to use tag. On the other hand, if you're getting views from another framework, or allowing another framework to manage views for you, it may use tag for its own purposes.
From your question, it appears the former is likely the case, but if you need stronger guarantees, you're better off adding another property which more directly identifies the views you'd like to be using.
You also haven't specified what you want to use tag for, necessarily, but if you just need to store an Int that's completely unrelated to identifying the button, I'd advise against using tag and instead add a semantic property that describes what you're trying to store. (Tags are also meant to be unique, which arbitrary data might not be.)
With routing/routes defined in the manifest.json and using Router.navTo() to change the hash and the content of the target App control, I noticed that the "old" views and controllers are still hanging around and listening to events (e.g. performing binding updates for controls that are no longer visible on the stage).
I (wrongly) assumed that the router would clean these views/controls up for me - what is the recommended way doing so?
You are correct. Before calling oRouter.navTo(...) you can call unbind. To give you an example you could check here. There you can find the following line of code inside the onNavBack handler:
this.getView().unbindElement();
unbindElement() is called because previously bindElement(...) was called in the same controller. So just make sure to use bind/unbind combination before oRouter.navTo()...
I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.
I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.
MSDN simply states that
If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.
MDN states
If a window does not have a parent, its parent property is a reference to itself.
And the W3 standard itself
The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document
I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?
So, why?
When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.
Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.
In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.
For instance, Bob is programming:
Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)
Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?
I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.
In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.
I hope I make some sense.
I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.
I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.
If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.
But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.
I`m using asp.net mvc 2.0 and trying to create reusable web site parts, that can be added at any page dynamically.
The problem I have is how to load a partial view with all related js and data? Ive tried the following ways to do that:
Use partial view and put all the js into it. In main view use render partial. But to initialize partial view I need to add model to current action method model to be able to make RenderPartial("MyPartialView", Model.PartialViewModel).
Also I do not have a place to put additional data I need to fill my form(like drop down lists values, some predefined values etc).
Use RenderAction, but it seems it have same problems as RenderPartial, except for I do not need to add anything to any other model.
Any other oprions are greatly appreciated.
As I understand it, RenderAction performs the full pipeline on the action, then renders the result - so what is rendered is the same as what you'd see if you'd browsed to the action.
I've used RenderAction to render 'widgets' throughout a site, but in my view they should be independent of the page rendering them, otherwise they're not really widgets and should be part of the rendering page's code instead. For instance, if there's a log in form, you will always take the user to a page that can process the information, no matter what page they are currently on, so this makes for a good widget. Other ways I've used it is to show a shopping basket or advertising. Neither of which are dependent on the page being shown.
Hope this helps a little!
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.