Design patterns for Android [closed] - android

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
I'm working in a new app for Android. Since it is my first time working with it, I don't know how structure it. I'm searching for a nice design pattern to use.
My application will make connections with a WebService and also, will save some information in local.
Which design patterns will be nice for my app?
I saw MVP pattern (Model-view-presenter) but I read it is focused to do tests.

WebService interface
Basically you have two main routes to achieve a WebService interface.
You can use the WebApps way. It is a WebView centered approach, in this way it is more remote-driven: you can upgrade the website css/html and make large changes to the layout and content without requiring your users to upgrade your app on the market.
You can also use the WebWorkers way. It is application/android centered. You use Asynchronous threads to fetch data from the website, on success, they call a Handler in your UI which is responsible for displaying it using a WebView or android widgets (ListViews for example). This is longer to code and (hence) more error prone but you can achieve a much better android integration (using Notifications, background checking, ListView based activities).
Information persistence
This really depends on how much information you want to store and how much you want it to be shareable the android way.
The best (and harder) android integration is achieved with a full-blown ContentProvider whose backend storing is delegated to sqlite. API Demos have nice code samples for this.
For a fixed number of data persistence, SharedPreferences is much simpler.
This article is a good tutorial on android data persistence.
MVP design
MVP is used throughout android framework, this is not a choice really, you have to comply with it whenever you want to use standard widgets ;)

You should read the application/activity lifecycle very carefully, writing code which properly fits into this life cycle limits the use of certain design patterns a lot: http://developer.android.com/reference/android/app/Activity.html
And you should really try to fit into this, it really helps to avoid a lot of strange problems :).

Related

Guidelines for what should be done in backend vs front end of a mobile app? [closed]

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 6 years ago.
Improve this question
I'm developing an android app which communicates with a backend and many times I find myself at the crossroads of deciding whether each decision should be made by the backend or the front end.
I've designed the structure, database management, etc on the backend, this is obvious. However, when it comes to access control, the lines become a little blurry for me. Take the following as an example:
Element A requires that User B have permission X to view certain details
Element A requires that User B have permission Y to view ALL details
Now, on the front end I can see the permissions but it's a lot more complicated to handle them than it is in the backend, but just flat out attempting to perform the operation by sending the request to the backend and reacting to its response would be more work for the backend.
In terms of best practice and efficiency, what would one do here?
If anyone has some good resources for best practices when working with a back/front-end and how to distribute the handling of operations, that would be incredibly helpful....thanks!
Security controls had to be made always in the backend to be secure.
If element A requires X to be able to view Y then Y can never never go to the client if it hasn't required permissions.
Then everything will depend somewhat on your application and offline experience you need
Every control should be on backend, as they can be change at any moment. And also if you hardcode those things in client side, firstly you are exposing business logic and on every change over those setting or controls you have to republish the app(in case of mobile app)
Really depends on what you're doing.
You can deliver permissions categories in your restful services so that your backend can do the heavy lifting.
The 3 Obvious things you have to keep in mind is:
We don't want the UI to wait for the backend.
We don't want the UI to be slow because of working hard on the main thread.
Secure things should not be exposed in requests.
I prefer to do the heavy lifting in the back end as much as possible and deliver a clean restful api using retrofit. preloading the data when I can and manipulating the ui asynchronously using placeholders.
I hope that answered your question.

How do I effectively implement the MVVM design pattern for my android app which will also ease writing of test cases? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am planning on implementing the MVVM architectural design pattern for my android app. I have read online that it will help me achieve efficient separation of concerns and easily write test cases for Data model, UI, etc. Need some insight/advice for this.
Well, to learn how effectively use MVVM, begin with Android MVVM Design Pattern Examples
Here you would find that post:
I am the developer of Android-Binding. Like #Brentley said, it's
a very new project but I do hope to get more buzz and experience so
that it can be improved. Back to your question, I have written some
simple introduction/tutorials on MVVM with android-binding:
Android MVVM Tutorials (with android binding)
Introduction to Android Binding (codeproject)
Model Validation in Android Binding (codeproject)
Wiki in project homepage
Potential adopters please also register on the project discussion
group.
Read whole topic. You would notice that MVVM is relatively new framework and it's highly recommended to work with it cooperatively with Google's pData Binding library and dependency injection library like Roboguice or Dagger2...
...but the best would be this one:
Approaching Android with MVVM. Building an MVVM architectured application using the Data Binding Library,
where an author is explaining using MVVM with Data Binding library by example - I mean by his own created app. He concludes:
It’s still too early to know if this approach is the correct way of developing an application, but this experiment has given me a chance to look at one of the possibilities for future projects. It’s something I definitely want to play around with more.
Model-View-ViewModel is interesting because in traditional Android architecture, the controller would push data to the view. You would find the view in your Activity, then set content on it.
With MVVM, your ViewModel alters some content and notifies the binding data framework about changed content. The framework do then automatically update any views, which are bound to that content.
The two components are only loosely coupled through that interface of data and commands.
Next aproach of using MVVM is really testable. From MVVM on Android: What You Need to Know
Because a ViewModel does not depend on the View anymore, you can test a ViewModel without a View even existing. With proper dependency injection for other dependencies, it is very straightforward to test.
For example, instead of binding a VM to a real view, one might create a VM in a test case, give it some data, then call actions on it, to make sure the data is transformed properly. (...) All of this can be done without having to interact with an actual View.
Read also: MVVM ON ANDROID USING THE DATA BINDING LIBRARY
Hope it help

Android Architectural patterns [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have just started with the android development and I am trying to develop my first application, which I am actually going to publish. I have a programming background in Java and knowledge of some patterns however I have no idea which patterns I should stick with while developing android apps. Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI. I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer. Between them I create facades to access the services of the layer bellow. I dont really know if I should stick with this structure or completely rebuild this app according to some other patters. Its better to find it out at the beginning of the development than to be forced to rebuild entire application later on. So if somebody could provide me with some links about architectural patterns which I can use or write something short about it here, I would really appreciate it!
In my opinion the single responsibility principle and separating whole application into different layers (such as MVC pattern but Android is not fully compatible with formal MVC) is a good practice in Android development.Now I will talk about major layers in the following:
Representation layer :
For instance Android framework offers a very straightforward XML representation for Presentation layer,In regard to this XML representation, you should not create the user interface stuff in code. Instead, you must do it by XML.
Application Logic layer:
For application logic layer it is good to accomplish it in code, not anywhere else, For example there is a android:onclick="function_name" attribute in Android XML(for assigning an onClickListener to a View) But as MVC pattern the View/representation layer MUST be fully separated from Controller/logic layer.
Data source layer :
Finally you can have a data source layer which its responsibility is to providing data, persisting data, and all data related stuff. In Android you would put some things in this layer such as dealing with SQLite, ContentProviders, SharedPreferences etc
Result:
I think it's better to pick a main architecture pattern and design your application in high abstraction level according to your picked pattern and then implements its sub-layers. my favorite approach for architectural design and implementation is something sounds like top-down approach, in this strategy you would design your application in top to bottom manner / more abstract to less abstract / less detail to more detail
I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer.
Alternatively you could divide the app vertically by its features. So you get a package for each feature or activity, perhaps with subpackages. A good rule of thumb is: a package should not contain more logic, than you (or someone else) can easily understand. This technique has some advantages. First, your packages do not become bigger and bigger when you add more features to your app. Second, it becomes easier to maintain dependencies between different features. Perhaps your IDE can generate a dependency matrix of your packages.
Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI.
Android has the concept of Loaders and AsyncTasks. They help you to seperate long running tasks from the UI. There is an example using the Loader-API on the Android developer website.
You might want to put your network communication in a Service instead of AsyncTask or Thread.
Your architecture sounds like some form of MVC which is good in my opinion.
I think the Activity is a good starting point for you. Learn it's lifecycle and how to present your data to the user. You can also read more about threads and connectivity to see for yourself how it's done in android.

how to know about classes,methods and imports? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am a computer science undergrad. I am passionate about programming. I studied c and c++ at college. I learned android on my own. i created 2 apps following youtube videos. and then i wrote comments to those code by reading some of the android programming books. i learned so many good stuffs.
now i am trying to create my own app and i have ideas but do not know how to know about imports,classes and methods that i can use...and i do not know if there are classes,methods that can be use to turn my dream app into reality....how to know about classes,methods,imports!
i know about developer's site but how to use it..i mean how to get things done ..can anyone give some example?
like i want my splash screen to be there for 10 secs now how to know required imports,classes and methods....i always go crazy over internet and start to search how others have done and imitate it..what is the real way of learning those stuff?
i am really eager to learn on my own.
You seem to be asking for a superior strategy to help you identify the Classes and methods that you will need to use. I don't think such a strategy exists, but I would suggest a couple of ideas:
Get a good textbook on Android app development, and read the initial chapters, and all later chapters that appear like they might be relevant. This should give you a start on understanding the APIs.
Read through the package-level documentation for all of the packages in the libraries ... including the "java" ones. This will give you an overview of what is available.
Look for relevant tutorials and example code to read / borrow from.
From there, it is largely a matter of intelligently searching the Android API docs. In the case of Java SE and EE, the javadocs include indexes of methods and all classes, together with a type hierarchy and a usage index. I find that searching these using a web browser's page search can be productive. But the most important technique is intelligent choice of keywords for your searches. (If your working vocabulary of IT English is not good, this could be a challenge ...)
I recently started learning how to develop Android apps as well. I learned by reading books and studying the online Android documentation. The books from Commons Ware are very good. You should also study general Java programming concepts. I recommend [Learning the Java Language] from Oracle's Java Tutorials.

What is the standard way to organize Android code in project [closed]

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 8 years ago.
Improve this question
I'm new in android, I want to know what is the right way to write a code in an android project or which architecture or model should we use in our project
example n-tire, MVC or other?
check out this thread:
Tips on organizing larger Android projects?
and this one:
MVC pattern on Android
and this one:
Which design patterns are used on Android?
and this one too:
Android MVVM Design Pattern Examples
Organize it in whatever way makes the most sense to you. There's no 100% correct way to organize an Android project... it depends on a number of factors (i.e. the size of your project).
If you want to see how Google organizes their projects, take a look at the Google I/O 2012 source code. In particular, check out the iosched.util package... it gives a number of ways to reuse code across your project (mostly by using static utility helper methods).
This is actually a debatable question, but I will give my two pennies.
Considering Android is a portable system you need to consider that your application will not have unlimited power, and the power it does have has to be shared with other applications running on the system, by power I mean battery life, considering a large number of Android devices are actually quite healthy in terms of CPU and RAM, however even though most devices have more RAM these days, this RAM is still shared with other applications, so it should be used sparingly.
That said, any elaborate, highly engineered solution that prefers layering and abstraction over simply 'getting the job done' will probably suffer in the long run, the bottom line is the less instructions your application executes and the less memory your application uses, the more efficient it will be.
To give a more practical answer to your question, I would first make sure you are comfortable with core Android components such as content providers, services, broadcast receivers, intents and handlers, etc and work out from there.
Sorry for not giving a more specific answer, but I hope that helps a little.

Categories

Resources