A simple, scalable app architecture with Android Annotations Luke Sleeman Freelance Android developer lukesleeman.com.au

Transcription

1 A simple, scalable app architecture with Android Annotations Luke Sleeman Freelance Android developer lukesleeman.com.au Image CC: Luke Sleeman - Freelance developer specialising in Android and today I m going to be presenting A simple, scalable app architecture with Android annotations

2 Agenda Introduction The architecture - History, Goals, Overview Services Domain object Testing UI Closing thoughts I will be presenting an overview of the architecture, then we will be diving in and exploring various components of it in more detail, including: Service, the domain objects, testing and the UI Very code heavy. Medium to advanced audience.

3 History The architecture I will be presenting today grew out of my needs as a freelancer I would come in to a job and I would either be doing new development or enhancing and existing app, and I needed a go to application architecture The architecture I have been presenting has now been used for 3 years now - stood up very well. There has recently been a lot of talk about how to architect android applications. What I will be showing today holds up very well against other proposals.

4 Goals Quick, simple Typically data driven apps - get some stuff from a web service, store it locally, show it to the user, submit stuff back to the web service Scalable - Handle small apps and big ones Unsurprising, easy to jump in and out of, clear and concise, makes sense to anybody. Obvious. Testable Boring! A good way to understand an architecture is to understand how what its trying to achieve. These are the main drivers for the architecture I will be presenting today

5 The architecture! User Interface Domain objects Services Three tiers - surprising yeah! Its probably the most common architecture out there Well, the reason its so common is it works and everybody understands it Briefly explain the 3 tiers Services contain services - these things talk to the DB, talk to webservice, load and save domain objects. Whenever the UI wants to get a list of domain objects, or save them, it talks to the service Domain objects - contains all of our business logic. This is where the java 101 class person lives, with getname and getage UI - All our activities, fragments, views, adapters etc

6 This is what it looks like You could even break these things out into their own project if it was big enough Conversely if you only have a 3 or 4 classes, just put them all in one place!

7 What is AndroidAnnotations? Annotate your code - works of JDK annotations Code generation - you can look behind the curtain to see how the magic works. MyActivity_ Includes annotation support for a lot of other libraries I use such as ormlite You don t have to use it But you would be silly not to :-) There are plenty of other similar libraries (retrofit, butter knife, dagger) There are lots of annotations - This isn t an introduction to aneroid annotations, we will only cover the ones of interest to our architecture

8 So what about Android annotations? Domain objects Services AndroidAnnotations User Interface Android annotations acts as a glue which ties it all together Supports and strengthens each layer - so instead of reading inner classes, callbacks and boilerplate, its easier to see the intention of the code

9 Services User Interface Domain objects Services Can do many things: DB access, WS access, Saving and loading data, files, etc. Utility code Big or little - as small as a few static utility methods You can have one or many services in your app Always singletons, always stateless

10 Typical methods List<Users> getusersfromwebservice() AndroidDatabaseResults searchforsite(string searchtext) UserInfo getinfofromfacebook(int key) Here are some typical methods that you would expect to see in a service object Talking to web services Querying the DB Talking to 3rd party libraries and services - you can wrap up and hide all the complexity

11 A Simple Service public class PizzaService { private static List<Pizza> pizzas; public static List<Pizza> getpizzas(){ if(pizzas == null){ pizzas = new ArrayList<Pizza>(); pizzas.add(new Pizza("Luke Special", 10.50)); pizzas.add(new Pizza("Margherita", 9.50)); return pizzas; Here is a very simple service for an app with no DB and no webservices, which displays pizzas. The service is responsible for building the pizzas and returning them

12 A more complex = EBean.Scope.Singleton) public class FriendService = ExampleDBHelper.class, model = Friend.class) protected RuntimeExceptionDao<Friend, String> protected FriendListWebservice webservice; public List<Friend> getfriends(){ return friendsdao.queryforall(); public void downloadandsavefriend(int id) throws IOException { Friend newfriend = webservice.getfriend(id); friendsdao.create(newfriend); Here is a more complex service built with AndroidAnnotations. You could do all this without AA, but you wont fit it on one slide! Part of a social networking application Point out parts of code Note that the web service code is synchronous! We will discuss this more when we get to the UI. Also note that it throws exception. This is because the UI might want to do different things based off different exceptions

13 Domain objects User Interface Domain objects Services POJO s. Sometimes called model objects. Represent entities in the business domain - Person, Article, Order, LineItem, Message Hold onto the data while its passed around in the app Contain business logic - any tricky business rules go here!

14 A simple domain object public class Pizza { private String name; private double price; public Pizza(String name, double price) { this.name = name; this.price = price; public String getname() { return name; public void setname(string name) { Here is a simple domain object. There really is nothing special about it and I may or may not have copied it from my 1st semester java notes :-)

15 A more complex domain public class Friend = true) private int private String username; public int getid() { return id; public void setid(int id) { this.id = id; public String getusername() { return username; Again, there is really nothing to special - we do have some annotations Explain annotations Point out that those annotations are not part of AA - they are from OrmLite

16 Domain objects Relationships Your domain objects are probably going to have relationships - one to one, one to many, etc

17 Domain objects Relationships Option 1 - In the = "user") private List< Address> addresses; Option 2 - In the service public List< Address> getfriend s(int id) Your domain objects are probably going to have relationships - one to one, one to many, etc There are two places you can put them - in the domain objects and in the service Where they go depends on how the objects will be used by the UI. Put too much in the objects and you will have to pull down the whole tree. Put too much in the service and you will just have reams of loading code A good heuristic is to split the domain object tree where screens are split. If you have the addresses on the same screen as the people, then include in the objects. If they are different screens in the DB.

18 Unit tests User Interface Unit Tests Domain objects Services Test talk to domain objects and services. They act like a bit like the UI. They don t test the UI I ve found that UI tests don t give good value for money. If you UI contains complex logic and you feel you want to test it, thats a good signal to move it into the domain. Tests-first is good too.

19 Some basic tests public class PizzaTest extends AndroidTestCase{ public void testgetpizzas(){ List<Pizza> pizzalist = PizzaService.getPizzas(); assertnotnull(pizzalist); public class FriendTest extends AndroidTestCase { public void testfriend(){ FriendService friendservice = FriendService_.getInstance_(getContext()); assertnotnull(friendservice.getfriends()); Here is two very simple unit tests - one which uses a static service and one which uses an Android Annotations EBean Just wanted to point out this is how you get a hold of the EBean if you are in the service

20 The UI User Interface Domain objects Services The UI contains all the standard stuff you would expect - activities, adapters, views, etc Importantly it also handles the threading!

21 This is where android annotations @ListClick The UI is where android annotations really shines. And thats because the UI is the part of Android that is most fraught with boilerplate Explain what each of the annotations do

22 Getting services and domain public class BestFriendActivity extends Activity protected TextView protected FriendService friendservice; private Friend protected void setupbestfriend(){ bestfriend = friendservice.getbestfriend(); protected void poke(){ friendservice.poke(bestfriend); Here is a simple example of a basic Activity which uses android annotations. Of course you can do all this without AA Explain each of the annotations

23 public class FriendListActivity extends Activity protected ListView protected ProgressBar protected FriendService protected void startdownload(){ progressspinner.setvisibility(view.visible); downloadfriends(); Threading and keeping network activity off the UI thread is a huge problem in Android. Its not that we don t have plenty of good solutions (async task, async-http) but they all require so much boilerplate! Here is an AndroidAnnotations solution that is much simpler This is just the setup - a basic activativity. The magic happens in downloadpizza

24 protected void downloadfriends(){ try{ List<Friends> friendlist = service.downloadfriendlist(); displayfriends(friendlist); catch(ioexception e){ protected void displayfriends(list<friends> friendlist){ protected void displaydownloaderror(){ progressspinner.setvisibility(view.gone); Here is the actual magic not that there is much there Background thread runs in the background UI threads run on the UI thread So here we are handling some fairly complex threading work in a simple and concise way

25 There is a bug! Some of you may have noticed a bug in the previous slide.

26 protected void downloadfriends(){ try{ List<Friends> friendlist = service.downloadfriendlist(); displayfriends(friendlist); catch(ioexception e){ protected void displayfriends(list<friends> friendlist){ protected void displaydownloaderror(){ progressspinner.setvisibility(view.gone); What happens if thread takes a long time and the user leaves the methods will still get run and app will crash

27 Threading - dealing with activity shutdown Option 1 - Let our background task run and don t update protected void displayfriends(list<friend> friendlist){ if(isdestroyed()) return; Option 2 - Cancel background = "download") protected void protected void ondestroy() { BackgroundExecutor.cancelAll("download", false); super.ondestroy(); Two options don t update ui, or cancel Doesn't matter which you choose, but be consistent!

28 Closing thoughts

29 Closing thoughts Architecture is important! Architecture doesn t have to be complex - Keep it Simple! You need to be constantly thinking - What does this add, is it worth it? Hope that what I have presented today provides some food for thought. We have seen a lot of discussion about architecture over the past few years - this is good! However some of the proposed architectures I have seen, seem hell bent on replicating the worse excesses of enterprise java. Remember the first of my goals was to have an architecture that is quick and simple Hope that what I have demoed today provides some food for thought, encourages you to look at your own lightweight architectures and try out android annotations

30 Questions?