Android is a versatile OS with more than 1000 device manufacturers and more than 18000 distinct devices. Screen size of android phones vary from 2.6” – 6” and the resolution of screen ranges from 240 X 320 to 1440 X 2560 px with screen density from 120 to 640 dpi (ldpi to xxxhdpi). It is difficult for designers to create such designs which work well on all these devices irrespective of the size, density and aspect ratio of device and still stay developer friendly. In this blogpost I will discuss some useful techniques that ease out the painful design implementation in Android devices that I’ve learnt over a period of time.
Android’s way of dealing with this diversity:
Android provides basic structure to support these devices by putting them in different density buckets i.e. ldpi, mdpi, hdpi, xhdpi, xxhdpi and xxxhdpi.
Activities, services, fragments, helper classes etc. are main components of Android applications but its tricky to establish communication between these components. It’s tricky when one cares about writing reusable code – loosely coupled, plug-n-play-able. The goal here is to avoid tight coupling.
Tight coupling – Components keep references of each other and call methods on them directly. In the code below, we are keeping a reference of MagazineActivity inside MenuFragment. So, MenuFragment is tightly coupled with MagazineActivity i.e., it cannot function without MagazineActivity.
This is the last part of this 6 part series about Fragment Oriented Architecture in Android applications. In the previous post I talked about managing sessions in fragment oriented application. In this post I am going to talk about retaining view hierarchy of a Fragment after removing it from container and then coming back to it by popping the backstack.
When a fragment gets replaced by another fragment and the transaction is added to back stack, the expectation after a popBackStack() is to return to the previous fragment with its UI state intact. Activity backstack takes care of this expectation quite cleanly until a low-memory situation occurs. But in case of fragments, this isn’t the default behaviour. In a vanilla implementation, the replaced fragment’s view-hierarchy would get recreated upon returning back to it. Reason is that during a replace operation, all the destructive life-cycle methods get called till
onDestroyView(), which wipes out the view-hierarcy. Upon returning back, all the constructive lifecycle methods right from
onCreateView() get called, thus, recreating the view-hierarchy totally afresh. Reason for this flow is to keep ‘Fragments’ memory friendly. Without the view-hierarchy, a fragment is just a java object with a bunch of instance variables.
This is the fifth part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about efficiently handling back button press inside fragment. In this part I am going to talk about session management in Fragment oriented application, by explaining integration of Facebook SDK.
In a fragment oriented application, we can conveniently manage all session related code in the activity and all its fragments would utilise it. Facebook SDK is quite in sync with this approach. Implementation of Facebook session is closely bound to an activity. And then this session is accessible throughout the application. As has been discussed before, if an application requires to sign in from different portions of it, it will be way more convenient to have those portions as parts of the same activity. So that the authentication code need not be duplicated.
This is the fourth part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about Inter-Fragment Communication. In this part I am going discuss about elegantly handling back button press inside fragments in a fragment oriented application.
Android devices have a hardware back button which normally serves the purpose of going back through the screens/actions stack. Callback to a back button press event is received in the foreground Activity (
onBackPressed() event callback) which can be overridden and handled.
This is the third part of a 6 posts series on Fragment oriented application architecture. In the previous post I talked about Transaction BackStack and its management. In this part I am going to talk about Inter-Fragment Communication. It’s a general concept, not deeply linked to the context of this series.
It’s a communication pattern over which fragments should talk to each other. Ideally, a fragment should never keep a reference of another fragment or even, in best case, of the specific parent activity. So, how would two fragments communicate? Consider the following scene.
This is second part of a 6 posts series. In the first post I talked around basics of fragment oriented architecture. From this post onwards, I’ll be talking about it’s implementation details.
In this part I am going to talk about Transaction Backstack and few related methods that can be used frequently.
Transaction BackStack has often been misinterpreted as backstack of fragments. FragmentManager inside an activity deals with fragment-transactions rather than with fragments. An entry into this backstack is a ‘fragment-transaction’ which can be composed of one or more operations involving fragment(s). Reverting this would revert back all these operations together.
FragmentTransaction ft = getFragmentManager().beginTransaction();
Above, is a single transaction clubbing multiple operations.
This is a series of 6 blog posts which explains about Fragment Oriented Architecture in Android applications. In this first post, I’m going to explain what is Fragment Oriented Architecture and why shall one care. In subsequent posts I’m going to talk about following topics.
Recently in one of our e-commerce projects we implemented phone verification for users to have authentic accounts at our website. The requirement was to have one account per user to avoid misuse of offers provided by our service on scenarios like signup, high-value purchase, referring a new user to shop at our site plus other special offers.
So we decided to verify users using phone number verification that seemed more reliable than email verification since having multiple phone numbers is not as easy and rare as compared to having multiple email accounts. We then chalked out a simple approach that came out ineffective and needed a renovation.
Save a phone number corresponding to a user that he can verify later by the one time verification code sent to his phone. We then ensure that the phone number is not verified against other account to have an account per user on verification request. Things seemed to go well but didn’t serve the purpose as expected.
During our revisit to the approach we found out that a user still could create multiple accounts. If you missed it too, here is how it goes:
Suppose, a user say, Haitham signs up with account A1 and verifies his account with number, N1. Now once he needs another account to avail more offers he can simply edit his number to say, N2 and not verify it. Then he can create another account say A2, and verify this new account using N1. As in the application’s use case of ‘referring a new user to shop at our site’, he could add himself as a referrer using account A1 for A2. Hence, the whole idea of fraud detection and prevention was deceived.
Don’t associate a number with a user until the user verifies the number.
The simple change above solved our issue to all possible levels.
Preparing your app for Android L ?
While using native executables in our existing Android apps we observed that those executables were no more working with Android L. We came to know that Android has introduced one more security feature starting from Android L i.e
Executable must be PIE (Position independent executable).
To compile a library adhering to above security feature you just need to follow these steps:
- Set following LDFLAGS or linker flags :
--with-pic option while configuring the library.
Some libraries might use different configure options to compile the code with PIC (Position Independent Code) so to check all available configure options for PIC you can use this command:
./configure -h | grep -i pic
If there is no PIC option in configure script then you can try passing
-fPIC option with your CFLAGS.
Now, compile the project (make, make install) and it should generate PIE.
To check if you’ve successfully generated a Position Independent Executable (PIE)
You can use “hardening-includes” package on Ubuntu or Debian.