Android coding best practices/design patterns [closed]
Asked Answered
F

4

30

In a recent question I asked I was directed to this website: http://developer.android.com/design/index.html

Amazing site, but it didn't answer one particular question: What are the best practices/design patterns to apply in the design of an application code-wise?

I did lookups for MVC/MVP, etcetera, and while that yields results, it's only about the actual implementation of said patterns, rather than other available options and such.

I tried decompiling and analyzing various apps Android installs by default, like the Market, but I couldn't really find a structure in Google's code. Does anyone have tips on how to setup Android apps in such a way they are maintainable, extendable, etc. I am aware of the wide meaning of these words and that they are purely subjective to the programmer for that matter, but I can't express it any differently.

One best practice I already encountered is one view per Activity and having lots of Activities in the app for the backstack to work properly, but other than that, I have no clue how to actually setup the Activity itself.

Fjeld answered 26/3, 2012 at 8:40 Comment(4)
I would advise you create a naming convention of your own that you can use in your project. For example, name Activities and Fragments so you know what is what without having to open it up. Do the same for your layout files too. Also, make sure you have a sensible package name and separate your classes out in those. Otherwise, just make sure you can read it, and you will be fine :)Pilcher
Ofcourse, I'm usually mixing Java conventions with a bit of CamelCase. You could call me OCD when it comes to naming conventions and enforcing them - even calling out my co-workers about it :P I "love" clean code :3Fjeld
#3235880 may have some answersRuy
slideshare.net/retomeier/… and #2961549 are good collections, too.Galloot
D
4

You should watch (from Google IO 2011): http://www.youtube.com/watch?v=WGIU2JX1U5Y

It's not about ICS but about honeycomb but it's still very interesting...

You will see that the ActionBar (there are also some libraries that make you implement the ActionBar on older versions of android) is getting more important and can be found in most google apps for android...

Also the ViewPager is used alot (for swiping horizontally between different tabs/views), like in the market...

To keep your project clean, you could give every activity a separate xml file, recurring elements you use should be kept in a separate xml file that you can include in every other xml file (footers, headers, separators,...)

Hope this helps you along!

Distillation answered 26/3, 2012 at 8:52 Comment(5)
Thank you for the video. The question I was referring to was about the ActionBar, so I'll be sure to use it as I like the concept of it aswell. I am indeed looking for tips like your last paragraph and now that you said that, I noticed hundreds of XML files in the Market source. Please keep those coming, would love some more tips - maybe even code examples.Fjeld
I read an article about the Play Store (market) and why it sucks... I can't find it now but I think the author was right in his argument: The current design of the Play Store is totally different than other apps from google, it's dark while other google apps are light and more userfriendly... So I would look more into Calendar, Gmail, Messaging, People app for good layout practices...Distillation
From what I could tell it was a mish mash of different packages, seemingly unrelated and bloated classes, hence my question if there are any good conventions to follow - or if everyone is just doing what he thinks is right.Fjeld
More code related: static views = 1 xml, for dynamic views (like a detail screen where you have to hide most cells and show only a few) in this case I prefer creating my layout from code where I take a LinearLayout as container and add only the needed cells...Distillation
For returning elements use includes and for returning layout attributes (like you would have in html h1, h2,...) use StylesDistillation
S
19

First of all, read the API Guides in particular the parts on Activities and Fragments. But if you've got the time, read all the API guides, they are a really great resource for understanding Android development.

Depending on the Android devices you want to support, I would recommend using the v4 Support Library and the v7 Appcompat Library. The first one (v4 Support Library) I use always because of the support for nested fragments (getChildFragmentManager() - not supported natively on < API 18) and the ViewPager. The Appcompat libary is mainly for supporting the Actionbar on devices with Android versions below 4.0.

I would also study Gradle as your build system and [http://developer.android.com/sdk/installing/studio.html](Android Studio) (free) or IntelliJ IDEA (commercial) as your IDE.

Considering third party libraries, the library stack I see mostly used these days (and use myself for the most part) are:

  • Guava as a general Java helper library.
  • Dagger and ButterKnife for dependency injection.
  • OkHttp as the HTTP transport library.
  • RetroFit or Volley as REST libraries.
  • Picasso as an image loading library. Having a good image loading library when you need to download/display images from the server is really important in Android because it takes care of memory handling and caching, which can be really hard if you try to do it all by yourself.

Alternatives that are also used a lot are:

Other libraries I use and recommend:

Chris Banes (a wellknown Android developer) recently released the source code of one of his applications which you can use as an example of how to build an Android app using several of the libraries mentioned above.

Seller answered 18/7, 2014 at 8:37 Comment(0)
W
18

The first thing that you got to learn is about Android activities really really well. Grok the whole thing. It'll be much easier to go forward from there. Do not go into Java design patterns so early as you would end up trying to fit the problem to your pattern which doesn't end well. Go through the examples on the Android developer website and then write as much code as you can.

I just put together this website called Android App Patterns - http://android-app-patterns.com and it showcases the different UI elements and interaction patterns some popular apps adhere to on Android.

There are a number of libraries which help you implement the above patterns easily. For ex.:

  1. GreenDroid - https://github.com/cyrilmottier/GreenDroid
  2. ActionBarSherlock - https://github.com/JakeWharton/ActionBarSherlock
  3. Android View Badger - https://github.com/jgilfelt/android-viewbadger - Will be used for notifications
  4. NineOldAndroids - https://github.com/JakeWharton/NineOldAndroids - Use HoneyComb's animation API all the way back to version 1.0
  5. Ignition: https://github.com/kaeppler/ignition - Lots of helpers for common Android stuff
Warmblooded answered 26/3, 2012 at 9:9 Comment(4)
Thank you for those links, GreenDroid seems interesting. Your site is amazing as well, awesome overview of cool designs!Fjeld
Thank you. :) Have to add some more stuff there as soon as I get time.Warmblooded
seems till now the libraries are all out of date(no longer maintained) :(Derrickderriey
Your website is amazing! I love the idea. Lots of inspirations for cool designs.Precise
D
4

You should watch (from Google IO 2011): http://www.youtube.com/watch?v=WGIU2JX1U5Y

It's not about ICS but about honeycomb but it's still very interesting...

You will see that the ActionBar (there are also some libraries that make you implement the ActionBar on older versions of android) is getting more important and can be found in most google apps for android...

Also the ViewPager is used alot (for swiping horizontally between different tabs/views), like in the market...

To keep your project clean, you could give every activity a separate xml file, recurring elements you use should be kept in a separate xml file that you can include in every other xml file (footers, headers, separators,...)

Hope this helps you along!

Distillation answered 26/3, 2012 at 8:52 Comment(5)
Thank you for the video. The question I was referring to was about the ActionBar, so I'll be sure to use it as I like the concept of it aswell. I am indeed looking for tips like your last paragraph and now that you said that, I noticed hundreds of XML files in the Market source. Please keep those coming, would love some more tips - maybe even code examples.Fjeld
I read an article about the Play Store (market) and why it sucks... I can't find it now but I think the author was right in his argument: The current design of the Play Store is totally different than other apps from google, it's dark while other google apps are light and more userfriendly... So I would look more into Calendar, Gmail, Messaging, People app for good layout practices...Distillation
From what I could tell it was a mish mash of different packages, seemingly unrelated and bloated classes, hence my question if there are any good conventions to follow - or if everyone is just doing what he thinks is right.Fjeld
More code related: static views = 1 xml, for dynamic views (like a detail screen where you have to hide most cells and show only a few) in this case I prefer creating my layout from code where I take a LinearLayout as container and add only the needed cells...Distillation
For returning elements use includes and for returning layout attributes (like you would have in html h1, h2,...) use StylesDistillation
U
0

An Android application should be fast. Well, it's probably more accurate to say that it should be efficient. That is, it should execute as efficiently as possible in the mobile device environment, with its limited computing power and data storage, smaller screen, and constrained battery life. In this blog I am providing best practices to follow to design for performance. for more read

http://www.onsandroid.com/2014/10/android-application-designing-for.html

http://www.onsandroid.com/2013/01/android-best-practices.html

Upcast answered 11/11, 2014 at 9:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.