The general rule of thumb is that there should be no android specific code in view models to allow for easy testing.
I need to pass a bundle with lots of metadata to the view model to filter and then return to the view. The logic is pretty dense, it would best for the view model to handle this.
Are there any exceptions to this rule, such as using Bundle or other non-Activity or Fragment android classes? Or is there a suggestion work around?
This will probably get flagged, because it's very opinion based. There is no ultimate authority, as such, decreeing these things.
I personally have worked on some massive MVVM projects, both WPF and Xamarin, containing hundreds of thousands of lines of source code without a single line of code-behind anywhere. I can also honestly say that in the 10+ years I've been working with WPF I've never seen a single case where a problem wasn't solved elegantly by strict adherence to the paradigm. That's not to say some solutions weren't more verbose or convoluted...many most definitely were...but they were all elegant and, above all, robust.
Not everybody is as much an MVVM purist as I am. Josh Smith, one of the most respected authorities on WPF/MVVM, jokingly wrote in his book Advanced MVVM: "Others insist that there should never be a single line of code in the code-behind, based on the strange notion that code does not belong in the code-behind. What an odd bunch!"
The problem with any technology such as WPF is that the distinction between application layers is blurred at the best of times. We've all seen inexperienced WPF developers who, when faced with the power of XAML, start trying to cram as much logic into the view layer as possible. And then there are people who solve the code-behind problem by simply moving it into converters and behaviors, not realizing that these are really just a slightly more abstracted form of code-behind. (Not that I'm saying they shouldn't be used, I use them myself all the time, just keep in mind they are still view logic!)
So yeah, it's complicated. At the end of the day it's up to you, as the developer, to make the best and most sensible decisions based on the requirements of your project.
Related
I am looking to start writing apps for mobile devices. I know a little about this subjec, and I am proficient in both java and python. However, before jumping into creating apps I wanted to get the community's input on a question I have not yet found the answer to:
How/Where should I begin?
I understand this question is fairly general/basic for a community that focuses on solving/debugging complex programs, but if there is a recommended tutorial (or specific platform) that will help a beginner(such as myself), it would greatly reduce the frustration and amount of monotonous questions asked on this forum and others.
Regards
Coursera is offering 3 courses all using android development which started last week. That would be an excellent starting point for anyone:
https://www.coursera.org/specialization/mobilecloudcomputing/2
How/Where should I begin?
I don't know about you, but I often learn by example more than reading. You mentioned that you're proficient in java so thats a great start. After you understand the Android SDK it's really only the UI good practices you need to learn. So here's my suggestion.
Start off with something super simple. Let's say, create your own version of a calculator. Something that can add, subtract, multiply, and divide. This should be dirty, ugly, but works correctly.
After doing this, take a look at some other android calculators on the play store. Check out Simple Loan Calculator. I use this example because it offers a lot of android UI components. ViewPager, ActionBar, etc. Download this app, take a look at it, and try to mimic it. This should provide an idea on how to work with the android UI components.
What's next? After you have done these two apps you should be relatively ready to tackle your own project.
HTML apps are easy to port across multiple mobile platforms. I have set up an Android HTML template as a starting point. You can just import this project into Eclipse and take a look at that.
https://github.com/jakewp11/HTML5_Android_Template
Here is my experience for ios,
There are three things that I consider as pillars
Objective C
Memory managment
Design patterns
The first one looks obvious but I'd stress on learning concepts like protocols, categories, extensions. As a beginner I thought that learning the syntax was enough, but time and again I had to jump back to the language concepts to understand what's going.
The memory managment , the most talked and confusing subject and now since we have automatic referenc counting to make things simpler and often new Dev skips learning memory concepts (I did it). So I suggest you to have an idea what actually happens under the hood of arc " the manual memory managment"
The design patters,
When I started off , to pass data and control , what I used to do was achieve every thing through the only design patten I knew (target action) . I lack the knowledge of design patters didn't how easily I could achive better results with less code.
Some resources:
Dev.apple.com
http://www.raywenderlich.com (one of my best tutorials are here, you can find one on design patterns)
http://rypress.com/tutorials/objective-c/
And yes , the sample projects at Dev.apple are the best tutors.
After trying to make sense of the Metrics and Grids page of the (fairly new) Android Design website, I gave up on a lot of things. So, basically, I'm trying to find the original layouts that are used in Android 4, so that I can apply the same concepts.
To make this question more objective and not fail under the "too broad" axe of stackoverflow, I ask you for the layout that is used to recreate, exactly and fully, the examples on that page. Did Google provide them in the samples? Maybe a well known didactic repository that strives to conform with standards?
Just as an example, it's not clear what to do to recreate the "48/3 metrics" (16/16/16) in order to make the text fit in it. What if I want to use 1-line of small text? Would it be 16/wrap_content/16, or 16/16/16 to make it consistent with other layouts around the set? What if...
I believe this would not only help the small devs, but also and most importantly, help standardize the look and feel of apps in Android Play. The site is a good start, but far from ideal.
Added details
I never asked a question with this much upvotes, and I didn't even expect that (I have other questions that I regard as "better", but by far not as many votes and favs). Not that I care about votes, of course, but that is to show that there is a great demand for what I'm asking (a bit of an ad populum here, but still...).
Replies to comments
#Ricardo Amaral:
I'm indeed sorry if I wasn't clear enough:
Mandating a standard and requesting unambiguity from it are different issues. One of the reasons I like Android is the degree of freedom we have, so I'm very much aware of the impossibility of mandating most of the common practices.
I believe it relates to the concept of "reinvent the wheel" within the concept of freedom.
Again, those were just examples. Some things are not clear... which are paddings of the outer container, and margins of the inner views? Many times that makes a difference in selectors, dragging etc. etc. etc., and that again translates into a familiar look and feel for the user. One thing feels like splitting hairs, but it quickly adds up to a lot of small differences. And the user notices it... it looks like it lacks that last "finishing touch".
#Michael Slade:
I know they're examples, that they may have been wireframed from templates. As said, I'm already reusing code from the SDK, and I know they're just examples and that we can deviate from them. Again, after all this time, nobody answered.
Optionality benefits from precision. That's what I'm trying to say and ask. Because it's a recommendation doesn't mean its guidelines can be whatever you want them to be. If you do that, it's not the recommendation anymore. That's the whole point of recommendations, by the way: provide an implementarion theory without forcing anyone.
Thanks everyone!
Hate to break it to you but it's likely that the images on the page you like were created with a drawing program, and there are no example to go with them.
Without someone actually going to the effort to create samples for you, your best bet is to go through the samples that come with the android SDK - they will follow the guidelines in most cases.
And remember, they are just guidelines. At the end of the day it's up to you to create a pleasant and smooth user experience, however you see fit.
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've been through the Android tutorials - these do a good job of introducing how we can hand-roll an Android user-interface. Actually, I do not need that level of control right now... I'm looking for something simpler...
I'd like to make an Android app which will mainly contain a number of standard UI widgets, nothing particularly fancy. Having done some VB development a long time ago (yes, I know it's crap!) - I particularly like the ability to paint user-interfaces with an interface designer and then add in the relevant callbacks via the IDE. I'm using Eclipse, so for now solutions requiring net-beans or other IDEs are not particularly helpful.
I'm well aware that this practice often produces sub-optimal code, and less than beautiful interfaces. That's not really a concern here. I just need to produce a certain effect quickly in order to prove a concept. There will be plenty of time later on for optimization if my idea is good enough.
If you create a layout xml file you get "drag/drop" for the activity layout. It's not perfect, but you should be able to accomplish what you're asking for.
How you were used to VB development won't work out for you.
You will have to create your interface in XML, and put events to the objects by code. There is DroidDraw but it won't get you further then the plain inbuilt IDE of Eclipse.
When creating XML layouts think like it a HTML layout, nested objects, tables/linearlayouts etc...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In the same way a web or desktop app might have three or n tiers - UI, Business, Data for example - what is the suggested structure for an Android application? How do you group classes together, what layers do you have etc?
I'm just starting Android dev (an internet-based app that must respond to incoming notifications) and have no real feel for the structure I'm aiming at. Suggestions appreciated.
IMHO, Android "wants to" follow a MVC pattern, but view & controller are generally really coupled in activities.
It makes unit test harder and it's hard to obey to the Single Responsibility Principle.
I found a really nice Android architecture presented here, there could be an idea. Everything is loosely coupled, so much easier to test and edit.
Obviously, I'm sure there are a lot of others possibilities (like the MVP pattern (Model View Presenter) - and here are answers talking about MVP in Android), but you should still take a look on it.
I've been working on Android for 9 months now from a server-side background where full unit testing and layered architectures are common and work well.
Through lots of trial and error and I would strongly suggest using the Model View Presenter pattern, not Model View Controller.
A huge issue I've found is that Activities/Fragments have a lifecycle which is outside your control and can lead to unexpected issues.
For example, our main android app wants to be used in landscape mode on tablets. We do this in OnCreateView() or OnCreate().
On a Nexus 7, the default view is portrait so what happens is that it starts the activity in portrait mode, our code then says go to landscape and android ultimately creates the activity class 3 times!
We've hooked up network requests to onCreate and they end up happening 3 times in this case.
Sure, we can add logic to look for duplicate calls but, in my opinion, it would be better, architecturally to try and divide the UI from the business logic.
My recommendation would be to use the factory pattern to create presenters from the activity but make sure the factory only ever returns the same instance. The presenter can then contain logic to do network request, look for duplicates and return cached results and general business logic.
When results from network calls return, either post to a bus such as Otto which the activity (register for the event on onResume() and deregister during onPause()) has registered to, or make sure the callback interface implemented by the activity has been updated to the last activity in the presenter.
This way, code in the presenter downwards is unit testable and not reliant on flaky UI layer testing.
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you should not mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my oppinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then your anyway following a MVC pattern.
MVP is the latest architecute most people are following
Here is the small documentation As Uncle Bob's clean architecture says, “Architecture is About Intent, not Frameworks”
Watch this video it's just mindblowing good.
Here is a dedicated project for Android Architecture blueprints with well documented source codes. All of them are based on the MVP pattern with several twists. Also check the comparison of the various solutions based on lines-of-code, testability, cost of learning, their support for increasing data complexity. It depends on the particularly developed app and the context (time to market, developers, future plans, etc.) which blueprint fits best.