Last week we attended Droidcon 2014, held in Bengaluru. First thing we noticed was that we had underestimated it a lot. The event was humongous. With around 250-300 attendees, most of which were either cream Android devs or entrepreneurs.
The content selection panel as well seemed to have done a great job. Topics ranged from core technical (hacking through Android source code) to all the way upto UI centric stuffs (delightful user experience). The speakers were highly experienced and most of them were either business owners or with hands-on experience in product development. Even the promotional interactions were highly informative and bent towards their technical details.
Following are some talks we would like to mention particulars about:
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.
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.