I am very new to Android development and, while I get the general premise (and have even built a small application), I have been looking at other developer's source code to get an idea of how to better approach my development for larger projects.
One developer's code is read is basically using both XML layouts and Views for the various parts to the UI (similar to what is being asked in this question). I understand what he is doing, but it seems overly complicated to me. The XML layouts provide functionality already to create responses to actions. (For example, "onClick" is provided for most components in the XML.) Layouts can be generated very easily with the XML.
So, my question is - can I get away with building my entire application using just Activities and XML layouts? Can I choose not to use any Views? (Of course, this is assuming a relatively simple app - think task list or something similar.) Or, am I trying to simplify too much?
The general strategy I use is to push as much as possible into XML. It's a very different way of thinking from some other UI development systems, but it's very cool once you get past the learning curve.
I don't know what you mean by choosing "not to use any Views". Every UI component is a View of some sort. If you mean not using any custom View subclasses, then yes, it is definitely possible. The only reason to create your own custom View classes (and then use them in XML!) is when the stock widgets and views don't do what you want. Since they are quite flexible, this tends to be fairly uncommon (until you start getting into fancy behavior or need custom graphics behavior).
There are two ways for Creating UI for Android Application. They are
Using XML - You can use xml for designing UI targeted for supporting Multiple device. Also XML helps you to create Static components.
Java Code -Generally it's not a good practice to creating UI in java. Its suitable, if you creating a samll application. Its also useful when you want to develop application with dynamic components. If you want to create Dynamic Components in UI, Java code helps you to achieve this.
The Good Approach is to create UI via XML, unless there's no dynamic component needed in the UI. if you need dynamic UI creation then you go custom UI creation i,e., Using Java Code.
Since you are New to Android, i would like you to refer android developer site
I think you misunderstand, XML layouts are just a shortcut for creating views. You end up with the same results at runtime either way. Mix, match, use one or the other, it's up to you.
Related
I would like to know if someone know some Android Framework to conventional applications. For example, a framework like rails which we can see easily the MVC pattern.
See answer here for an overview of Android's limitations, which will give you an idea of why an MVC pattern on Android has not yet emerged: http://www.quora.com/Is-there-any-standard-MVC-framework-in-Android-application-development-If-not-is-it-worth-developing-one
After having posted that answer I have gone ahead and built a fully-featured app using a single-Activity architecture. It allowed us to get past all the major UX limitations that were mentioned while being able to have arbitrary complexity in controller hierarchies (parents with children with sub-children etc.). Overall it worked out great, however you WILL have to build out specialized components (ie: custom back stack mechanism) as well as to store/restore state in a way that plays nicely with Android's own Activity/Fragment lifecycle patterns. There are also certain limitations around Fragment animations which had us pull our hair out at times, which required more custom component workarounds. ie: animations that show both an outgoing and incoming Fragment on-screen at the same time aren't supported on Android, so you will have to resort to taking screenshots of views and placing them into temporary ImageViews so that you create the appearance of transitions that show two fragments at the same time. In the end it's all possible, but you will have to be ready to work around annoying Android limitations while keeping an overall MVC architecture intact.
In summary: make your top-level component an Activity which is primarily responsible for top-level navigation (tab-based, menu-based, etc., as well as back stack and state preservation). The top-level component should not govern any particular screen of your app, instead it manages controllers for every top-level screen. The controllers are all Fragments, and can contain sub-controllers which are also Fragments. All screen transitions are performed using fragment transactions as opposed to Intents/Activities. Passing around data between Fragments is another point of contention as Android generally only supports data-passing through an Activity (ie: Fragment uses its parent Activity). But in this architecture you have need to have Fragments passing data to each other (either parent/child or sibling-sibling relationships).
I don't have this wrapped up into a framework or anything, but if your dev/arch team is sufficiently proficient the architecture is definitely worthwhile shooting for. You will come out with an app that is not subject to the traditional UX limitations of Android... something that very few Android apps can say they've achieved. Also... it generally feels awesome showing you can achieve the same level of UX that iOS apps have for years. It's about time isn't it??
Don't know about the "conventional" part - Android does not play well with MVC architecture natively (mostly because Activities and Fragments take on responsibilities of both views and controllers), and I don't know if there is a standard framework for implementing MVC in Android.
I described some of my insights in more details in this answer.
That said, I created MVC (in fact MVP) template/tutorial application which demonstrates the approach I take to enforce MVP in my apps. You can use this app as tutorial, or clone/fork it and use as Android Studio template for your own apps. The source code is here: https://github.com/techyourchance/android_mvc_template
basically android has MVC pattern, but if you need more features like .net mvc you can use com.divankits.mvc module. Just see one of samples to find out how to use it.
here is more details about module:
bind properties to view(layout) objects
you are able to create field validators
convert model to json
After developing few applications, I know that many people like to add view programmatic ally.
But is it true that all XML layouts can be converted to Java code dynamically?
What are the pros and cons of using Java code to generate the layout?
The layout XML you are creating is being translated at run-time to java code.
So the answer to your question is Yes. You can do the same and basically create all your layout in java code from scratch.
The obvious down grade of this thehnic as you know is that it will take you much more time to achieve the same result as with the XML file.
So, unless you have to add view dynamically to you layout, I don't see a reason for you doing that process using java code.
But is it all xml layout can convert to java code dynamically?
Yes
What is the pros and cons of using java code to generate the layout?
According to the documentation the advantage to declaring your UI in XML is that it enables you to better separate the presentation of your application from the code that controls its behavior. Your UI descriptions are external to your application code, which means that you can modify or adapt it without having to modify your source code and recompile. For example, you can create XML layouts for different screen orientations, different device screen sizes, and different languages. Additionally, declaring the layout in XML makes it easier to visualize the structure of your UI, so it's easier to debug problems.
From Hello Android by Ed Burnette:
User interfaces can be designed using one of two methods: procedural
and declarative. Procedural simply means in code. For example, when
you’re programming a Swing application, you write Java code to create
and manipulate all the user interface objects such as JFrame and
JButton. Thus, Swing is procedural.
Declarative design, on the other hand, does not involve any code. When
you’re designing a simple web page, you use HTML, a markup language
similar to XML that describes what you want to see on the page, not
how you want to do it. HTML is declarative.
Android tries to straddle the gap between the procedural and declarative
worlds by letting you create user interfaces in either style. You
can stay almost entirely in Java code, or you can stay almost entirely
in XML descriptors. If you look up the documentation for any Android
user interface component, you’ll see both the Java APIs and the corresponding
declarative XML attributes that do the same thing.
Which should you use? Either way is valid, but Google’s advice is to use
declarative XML as much as possible. The XML code is often shorter
and easier to understand than the corresponding Java code, and it’s
less likely to change in future versions.
Pretty much everything that you can do in the XML can be done programmatically. I think it gets very difficult when it comes to drawable shapes and such.
I for one only do layout stuff programmatically when I don't know beforehand what I need to add.
Example: I have some Articles that can have 1- x descriptions, I don't know. Then I programmatically create TextViews that I add to a layout.
This question has been bugging me for some time. I've already developed a couple of apps on the Android platform and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable? Or should XML files be the go-to approach? I usually find XML a more tedious approach and often, these layouts don't look the same on all devices. I just don't get it. From a professional viewpoint, has anyone really been able to develop apps with complex views purely using XML files? This question is killing me because Google recommends using XML but the UI never looks the same on all devices unless done programmatically. Or am I doing something wrong?
Note that I'm referring to Android 2.2 and 2.3, which majority of the users use.
I use XML layouts on pretty much every fragment and activity of every app I write. I very rarely see any need to create Views dynamically, tho configuration of ListViews, showing/hiding views, etc needs doing in code. For me the advantages of XML are:
Ability to use layout editors (Eclipse)
Easier to preview layouts
Possible to benefit from auto-localisation of layouts
Easily maintain different parallel layouts for difference devices (screens)
Can get a sense of the layout by looking at it (easier than code)
Easy to break layouts down into pieces (fragments, includes, etc) to remove duplication
Keeps a separation between the visual design, and the functionality behind it
I can't think of any good reasons to put all my layouts into code - that sounds like hell.
I expect the reason your layouts don't look the same is because your XML is not defining the layouts correctly. Bear in mind the Android tools convert XML layouts into code, so there's no inherent problem with using XML layouts versus dynamic - both end up as code.
OckhamsRazor,
The answer very much depends on your needs, flexibility, and knowledge. The first thing to understand is that every Layout, whether created via XML or programmatically can be tweaked specifically or made to conform to many screens via properties.
... and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable?
Yes, it is. Android makes those available so you can do just that. However, the benefits of managing layouts via XML include standard MVC segregation, simpler debugging, and an easier time modifying the resource, if needed. Additionally, you may maintain multiple copies of Layouts depending on device configuration easily.
... has anyone really been able to develop apps with complex views purely using XML files?
Absolutely! There are some amazing programs that fully utilize XML rather than programmatic views. The key to them is how much information (that is non-standard view properties) is required from parental Views. Even in those cases there are ways to pass that information provided you know where and how to do so.
Or am I doing something wrong?
I don't think so. Honestly, I've run both ways depending on need. I'd say it really comes down to your lack of knowledge of the quirks. But the job is to get the job done. Here's an example: There are some times when I don't know how big everything needs to be until its run on the device, and there are times that I make the device conform to my layout's needs. Ultimately, I use the following chart to make my determinations.
Do I need information from parental Layouts that is aside from view properties
Do I need to dynamically size more than one element independently.
Is the View type pre-determined or will it change as well?
If the answer to 2 out of 3 of those is "yes", I will use some level of programmatic layout. If not, I will go pure XML. That being said, programming is one of those professions that encourages ingenuity (provided it is safe) and nearly anything can be accomplished in any number of ways. Ultimately, I'd say do whatever makes your job making quality apps easier.
Google makes its recommendations based on their own knowledge of software programmers and their general practices. They also created the platform, so they know which things are optimized in which ways. Its all about experience and we all have our own. If you have trouble utilizing XML, its worth taking the time to figure out the quirks simply so that it is another tool to utilize. Also, it will give you the information you need to answer this question for yourself.
To sum things up: I could say chocolate is better, but if you like vanilla, you'll disagree. Be aware of the drawbacks and benefits of each and take the time to learn how to accomplish the same tasks with both methods. It will make you a better programmer and give you a better sense of when to use which technique.
Hope this helps,
FuzzicalLogic
I typically do a lot of work with highly customizable UIs, where large portions of it need to be done in code. That being said, wherever possible I try to use layout fragments and inflate them, so as UI sections are added, removed, or rearranged I'm still just doing some of the layout, not all of it.
That being said, it's not that hard doing layout via code. The big advantage to it is compile-time checking. I'll find issues that way faster than using the preview pane. The preview pane can be nice for initial layout, but I use the Hierarchy Viewer for figuring out why my layouts don't look right.
It really depends on what type of project it is, or piece of a project, and what type of programmer you are. Some people just prefer pure code, while others like leaning as much on other tools for design as possible.
XML definitely has some benefits, like being able to switch between interface designs quickly. For specific design themes that are repetitive, is definitely useful for most programmers.
I personally prefer doing everything programmatically, and it is quicker for me to develop than writing XML, with the libraries and classes I have created. XML is quicker straight out of the box.
As for performance, there really isn't a difference worth mentioning unless you are using the same view so repetitively, at the same time, to the point that it no longer fits on the screen many fold. I did a test of how many text views Android could render on a Moto X - Android 4.4, and it couldn't get much over 5000, but there is never a purpose for that. If you are at that point, you are either need to dynamically load and unload data or are just doing something very wrong to begin with.
So learn both sides of it, definitely get to know the pros and cons with your style of programming, because there is no right answer for everyone, and let loose and have fun.
It is much better to separate the layout and put it in the xml file. I occasionally have to adjust the layout in code, but it is always an exception and only when I determine that it cannot be done in the layout .xml. If you use the layout views correctly, the application should look very similar on all devices.
I'm new in Android development and I have been making a tutorial for a game example which tells that using a layout file is not necessary because of the flexibility need on game development. However I've seen on Android docs that using a layout file is always the best way for Android development.
I'm sorry if my doubt looks obvious or kind of weird, but I'm really newbie and I'd really appreciate if you guys give me some help.
Most Android Games will use a Surface, Canvas, or GL Surface view to render all content to the screen. This element is likely to be fullscreen as well.
And so all drawing of UI and buttons and game elements are drawn directy to the surface, bypassing the use of Android's many UI views.
There is no reason you game cannot use android UI views in addition to using a surface for drawing the game action itself.
And of course you will likely use layouts as well when integrating things such as Admob ads or user dialogs within you game. So in practice you will use both.
But a standard utility application built in android will use layouts almost exclusively.
As a final aside, it is not necessary to use layouts. Every view type can be created either through XML layouts and inflating the views, or by instantiating a view in java code. the main reason for using layout files is because they are fast to build easy to use for a large category of interface design. But he choice to use them or not is your own.
A layout is used for arranging views. If you're not using any views (i.e. you do all the drawing yourself), then there's no point in using a layout.
For game development you are better off not using a layout file. The tutorial you are following is right. You will probably want to draw directly to a GL Surface View.
Personally, I forgo a lot of the features of the Android framework when doing game development. I use one Activity to bootstrap the game and get it running, and I draw to one GLSurfaceView. A lot of Android game dev tutorials follow this approach, and so are probably going to be a lot more useful to you than tutorials for more traditional Android apps.
I will try to keep this short, but I need some advice.
I work on a team that is developing applications for android, iphone, and wp7 in parallel.
We have a design team that comes up with a single design for all three platforms.
The latest application’s design is more marketing than productivity. The original POC for this app was done on the iphone. The design is very animation centric and most state changes are seamless (things will animate on and off the screen during state transitions).
If I keep developing against this design it means I will have to have everything in a single activity. So far, this has been a major headache. To my knowledge, dividing your application into activities is almost required. I could try to dynamically load and unload views as I change states but this doesn’t seem right.
I see where the design team is coming from where they want all these state changes to be seamless, but I don’t think this is right for android.
I would like to know what makes most sense. Should the design change to incorporate multiple activities or would it be worth trying to make this work.
We have a design team that comes up with a single design for all three platforms.
That's akin to coming up with a single floor plan to be applied to apartments, single family homes, and warehouses. The designers, or management, need to have their heads examined.
The latest application’s design is more marketing than productivity.
Did I mention that the designers, or management, need to have their heads examined?
If I keep developing against this design it means I will have to have everything in a single activity.
If I am interpreting your requirements correctly, that is probably accurate. While you can arrange for animations between activities, it is more of a "slide the old off, slide the new on", and I suspect that your requirements exceed that.
To my knowledge, dividing your application into activities is almost required.
It is certainly Android's intended development model for ordinary apps. However, games and the like may not follow this pattern, and you don't have to either.
I could try to dynamically load and unload views as I change states but this doesn’t seem right.
Depending on how many states there are, you might just hang onto all of them, recycling as you go.
I am surprised no one mentioned fragments which can be used instead of activities at many places.
Fragments can be seamlessly animated in and out or an activity.
You might want to take a look at subclassing ActivityGroup for your top-level activity. That can host multiple sub-activities. TabActivity, the only stock subclass of ActivityGroup, is perhaps not what you need because it includes a tab widget, but you can use it as inspiration for what you do need.
What specific headaches are you having with a single-activity architecture? Perhaps there are ways to make that less painful.
In general, if you are aiming to have native apps with a native look and feel, it is not reasonable to have a single UI design for all three platforms. The UI guidelines and user expectations for the systems are different, and those differences should be reflected in the UI designs.
If you really want to have a single UI for all platforms, just create a web app instead.
I'm not sure exactly what you mean by an "animation centric" design with seamless state changes. If you use multiple Activities, Android will animate between them in a way that Android users will expect. If you explain what exactly you are trying to accomplish, we can help you figure out if it makes sense in Android, and if so how to accomplish it.