Thursday, 11 June 2015

How email fails to share experience or help others..

- Help me Obi-Wan Kenobi, you're my only hope!
Projection light goes off and Obi-Wan turns to Luke...

Well we are all familiar with the scene right? Sending a holographic video message with an astro droid is pretty much like sending an email (it is electronic, send to a recipient can even have attachments :) ) and it saved the galaxy.

However, I don't think thats the case with real life. I started programming at an early age on Commodore 64, of course it was Basic. When I got my Amiga, I discovered a new more capable programming language called Amos. One day I managed to find a copy of an Amos manual. It was just a bad photocopy but come on it was much before internet and it was all I need to boost my coding skills on Amos. Very soon I became pretty popular between high school friends who are interested in Amos. I read code sniplets from the book on phone to help them solve their code issues.

Since than I enjoyed anyone who asked for help. Tried reply every single email, write blogs, give talks and even write a book (it is exhausting!!). However, a recent event just made me realize email is not the platform to share experience or help each other.

I was contacted by a kind lady whom was a friend of a friend seeking help. Basically she had an activity which fires a TimerTask to retrieve data from backend periodically. When the user navigates to another activity the dialog from the TimerTask continued to show up and actually that was it.

The email was actually not longer than a paragraph of text with the activity code.



Most of you may have already figured out what is wrong. The activity fires an AsyncTask but since the AsyncTask ran on its own thread, it has no idea if the activity is still in use, paused or even destroyed. However, there was more. The backend was a Secure SOAP Webservice. So each time the asynctask is executed, it creates a new connection, does login, prepares the soap message, makes request, decodes the soap response and finally displays the data which was actually only a two integer!

So I wrote a long detailed email to point each problem...


- Calling a soap webservice from a mobile device is waste of bandwidth. The backend service can be wrapped into a simple rest service which could serve the same 2 digit integer in either xml or json. This would also enable to encapsulate the changes in webservice.
- AsyncTask is easy and great but not for repetitive and long running jobs. Creating an asynctask is expensive. Besides creating asynctask periodically may also cause to follow the order of the responses. The proper way to retrieve data periodically from a backend would be either using Services or via ContentProvider (with or without a Loader). This way the connection can be created for only once and the login process doesn't need to take place each time. Also since the activity would either stop listening updates or unbinds the service so the data won't popup on other activities.
- Finally if all those create a huge burden (provided that this is just a school project, which need to be delivered tomorrow and won't go live ever) than Volley can be used instead of AsyncTask, which would cancel the request when the activity is not active as well as giving the option to cancel or pending requests.

Btw, my email started with asking if she would consider posting the question to StackOverFlow and if she does, I would love to re write the solution once again there.

..and she disappeared :) of course I am not expecting a box of chocolate or a thanks note but don't have any idea if she liked the answer or what level of fix she decided to implement. Besides all the data is lost forever, no one would benefit from my answer or may be her brilliant idea which overrides my solution.

So.. not really sure, email really helps and acts as a tool to solve problems or share knowledge at all..





Monday, 9 March 2015

Hitchhiker's Guide to Modern Android Development: The Pitfalls and Cryptic Errors

No platform or language is perfect, each has its own problems, pitfalls and cryptic errors of its own. Thanks to Java heritage, Android usually offers smooth, easily learning curve with a huge database of blogs, forums and stackoverflow answers.
After running and mentoring the Study Jam series for two weeks, I decided to compile a set of common pitfalls developers came across which tend to be cryptic or not google friendly.


Error: Gradle DSL method not found: 'runProguard()'
Possible causes:<ul><li>The project 'XX' may be using a version of Gradle that does not contain the method.
<a href="open.wrapper.file">Open Gradle wrapper file</a></li><li>The build file may be missing a Gradle plugin.
<a href="apply.gradle.plugin">Apply Gradle plugin</a></li>

This is one of the most cryptic error you may come across on Android. If you have been using Android Studio from Beta, you will/did probably face this error after upgrading to gradle version 0.14.0 (Android Studio 0.9). Simply the Android Tools team decided to rename runProguard to minifyEnabled. Similarly zipAlign has been enabled to zipAlignEnabled. You may find the full list of changes here.


Error:The project is using an unsupported version of the Android Gradle plug-in (X.X.X). The recommended version is X.X.X.
<a href="fixGradleElements">Fix plugin version and re-import project</a>

Similar to previous issue, this problem occurs each time you get an update to Android Studio and Gradle. Unlike the previous one, this can easily be solved by clicking the Fix plugin version link provided in the Gradle Messages window.


android.os.NetworkOnMainThreadException

You may come across this error if it is your first network call ever or you are updating an old app to post Honeycomb. Beginning from 4.0 (Ice Cream Sandwich) Android OS does not allow performing network operations on main (UI) thread which should have been this way since day 0. The main thread's main responsibility is running the UI smoothly. Networking, file i/o or any other lengthy operation will block the UI updates resulting in non smooth UI/UX. Networking might be the worst of all since the speed of the connection can rely on many different factors.
The solution is simple. Anything which is not part of UI should not be done in the main thread. Android offers an easy way to use threads which is called AsyncTask. Simply use an AsyncTask to perform lengthy operations.


I use an AsyncTask but still getting android.os.NetworkOnMainThreadException

To start an Asynctask, you need to call the .execute method on the Asynctask object. Calling the .doInBackground method will bypass the creation of a new thread and run the network operation on the main thread.


java.lang.SecurityException: Permission Denial: ... requires Android.permission.X

Android is based on linux and each app runs on its own sandbox with very limited permissions. If you need access a common system resource such as camera, bluetooth, internet or file system, you need to ask users permission. The permission are added to AndroidManifest.xml between the manifest and application tags. You can refer this for a complete set of permissions which can be added with uses-permission tag.


I added the permission java.lang.SecurityException: Permission Denial: ... requires Android.permission.X

Having a valid AndroidManifest.xml does not necessarily mean it is just working. Adding the uses-permission tags in the application tag, does not break the xml structure but doesn't reserve the permissions you asked either. List your uses-permission tags out of the application tag.


Permission Denial: … requires android.permission.WRITE_EXTERNAL_STORAGE

If you are sure you reviewed the previous two items but still getting the error, this should be because of the android:maxSdkVersion="18" property inside the uses-permission tag. To allow your app to use the write permission above version 18 you need to remove maxSdkProperty.
<uses-permission android:name=“android.permission.WRITE_EXTERNAL_STORAGE"/>


My Fragment's overflow menu displays a menu item (settings) not in menu.xml

Fragments can add their own menu items by overriding onCreateOptionsMenu(). However this does not mean cleaning up the menu items added by the activity. Since a fragment is always hosted by activity and uses the activity's context, it would inherit such stuff from the hosting activity. The item which you believe (settings is given as the default menu item) is not relevant belongs to the activity. Navigate the menu.xml which belongs to the activity and remove the unwanted item(s).


The method replace or commit in the type FragmentTransaction is not applicable for the arguments 

You are passing a fragment object to a method which is expecting a fragment object but still complaining? Well, not all fragments are the same. Java's design allow classes with same names as long as they are in different packages. Android SDK team decided to introduce the fragment support package with the same class name (Fragment) but in a different package (android.support.v4.app.Fragment vs android.app.Fragment). Navigate to imports and remove the wrong import and add the appropriate one.


onOptionsItemsSelected(), onCreateOptionMenu(), afterTextChange(Editable s), onPostExecute() or any other method which should have been called is not called?!?

The @Override annotation must have been the most underrated annotation of all time. It exists for a very specific reason. Unlike C++ every method is virtual in Java. Thus, unless it is final any method can overriden. The @Override simply checks if the implementation is really overriding a method from the parent class. All the methods above has a typo which any level of developer may do. Removing the override annotation also removes the ability of the compiler to detect any typos in the so-called overriden methods. This typos may occur in the method or even in the parameter list. Simply if a listener or a method which should have been called will silently failed to be executed. You can easily detect such errors by placing the @Override to every overriding method.

Wednesday, 28 January 2015

Finally my book is out: Professional Java EE Design Patterns



Finally it is on ink and paper! Well or on a screen if you prefer :)

It was quite challenging and tiring to write a book which might be the most underestimated thing I have done in my life! I was lucky to have a great co-author and great people from Wiley (Adaobi, Mary, Jim...) without whom i would definitely end up just putting those into my blog.

You may find more details below and click on the pic to buy from Amazon, hope you enjoy ;)




Master Java EE design pattern implementation to improve your design skills and your application’s architecture.

Professional Java EE Design Patterns is the perfect companion for anyone who wants to work more effectively with Java EE, and the only resource that covers both the theory and application of design patterns in solving real-world problems. The authors guide readers through both the fundamental and advanced features of Java EE 7, presenting patterns throughout, and demonstrating how they are used in day-to-day problem solving.

As the most popular programming language in community-driven enterprise software, Java EE provides an API and runtime environment that is a superset of Java SE. Written for the junior and experienced Java EE developer seeking to improve design quality and effectiveness, the book covers areas including:
  • Implementation and problem-solving with design patterns 
  • Connection between existing Java SE design patterns and new Java EE concepts 
  • Harnessing the power of Java EE in design patterns 
  • Individually-based focus that fully explores each pattern 
  • Colorful war-stories showing how patterns were used in the field to solve real-life problems 
Unlike most Java EE books that simply offer descriptions or recipes, this book drives home the implementation of the pattern to real problems to ensure that the reader learns how the patterns should be used and to be aware of their pitfalls.

For the programmer looking for a comprehensive guide that is actually useful in the everyday workflow, Professional Java EE Design Patterns is the definitive resource on the market.

Monday, 12 May 2014

The needle and the damage done... Orcl vs Goog

Last week Federal Circuit overruled Judge Alsup's decision on Java API Copyrights. Minutes later tweets from Oracle employees started rolling out.


Mark Reinhold, Chief Architect of Java Platform and an engineer in Java Platform since from the very early days, was happy about the decision. However,  when I took my Android Developer hat off, even I was a bit worried about the decision. Let's go back few years which I am pretty sure Mark will also remember pretty well from his early Sun days...

In October 8, 1997 Sun Microsystems filed a suit against Microsoft for monetary damages of $35 million because of violating Java licence agreement. The real story was, just after its launch Java Applets took off and gained a huge popularity. Suddenly the web has transformed from static text pages to fancy animations. Dancing Duke logo was almost everywhere. Microsoft was very happy to adopt and integrate Java. Actually they even went further and wanted to make it better in their way which was definitely wrong and broke the compatibility between JVMs. Sun took action and sued Microsoft winning $20m, the largest cash they ever won over Java. It was a big war against an enemy and we were all happy and proud. 

However, Java did not win as we expected. We (the community) lost the applets. The moment Sun loaded their guns, Microsoft started working on .Net platform copying the whole vm, collections, code syntax and many other great ideas from Java platform. Meanwhile they also stop shipping JVM and pulled out the current deployed one. Suddenly the applet miracle has turned out to be a compatibility hell. Flash and Javascript fight to take over the place but both were not yet mature enough to fill the gap for some time.

Sun won against Microsoft but lost the whole desktop and web world. Applets and later swing has left to die and Java became a serverside language while retreating from the front end. 

Meanwhile mobile phones took off and Java once again gained a huge popularity. Java ME rocked the mobile world until iPhone was released and changed the whole mobile world. Almost all existing mobile phone, OS and platform producers were unprepared with such a fast and huge change. Symbian and all other major platforms which Java ME was deployed has died, pushing Java ME to a certain death. We can all blame iOS but the truth was Java ME did not receive any big updates to make use of the new tech hardware and put pressure on Apple or any other vendor to ship JVM with their devices. Oracle and Sun might have been left out of iOS but they haven't been in Windows Mobile either. I remember writing .Net based apps as Java developer just because I could not find a stable JVM on WM5 and WM6.

Meanwhile Google bought Android and launched another mobile ecosystem striking back far from behind. Unlike iOS, this platform was much more Java friendly. There were no JVMs but still there were some compilation tricks to make the developer feel that they were just writing Java code. Android became the only real survivor from the iOS revolution and became a huge player.

We may argue if Google did the right thing with creating another JVM standard or not but there is no doubt that they kept the Java community and the ecosystem alive by providing a mobile platform which uses Java language and JVM for development. Thanks to Android (and GWT), many developers installed JVM, Java tools and continue writing Java code. Believe it or not Google had a huge role on keeping Java and its community alive and health. Without Google's non-JVM Java products such as Android and GWT, Java might have already became the new Cobol being trapped on serverside only.

Today, with the latest ruling, Google can just walk away from Java language. Android is already huge so whatever language Google chooses to continue with will be accepted by the community no matter if they like it or not. However, taking Java out of Android will be the end of Java in the mobile world, lowering number jdk/jre installs, usage of java and damaging the ecosystem with a real fork this time unlike the current virtual one.

Finally back to tweets, Donald who is an OpenJDK guy and whom I also know from his previous work in eclipse send the following tweet...

Definitely Oracle will make a huge cash from this ruling but for the sake of loosing a big part of the ecosystem. I just wish at least community guys at Oracle would care more about the community than Orcl shares.

I personally believe APIs should not be copyrighted but let's forget what I, Oracle or the judges believe... This will be the end of Java on mobile forever! 

Ohh unless Oracle really thinks they can survive with JRE on Raspberry Pi...

p.s. There is no typo in the title, since this war only about money I though it makes sense to use the stock exchange symbols instead of full company names.

Monday, 28 April 2014

Managing Success in Devil's Triangle of Software; Projects, Project Managers and Developers

I am not a project manager of any kind and never interested to be one. I am not a huge fan of non-tech posts and talks but just had an incident which gave me the idea to post my thoughts and experiences.

First what is project management? Since there are projects we do need project managers and management right? But what about those github projects or hackathons which has rock solid outputs in lightning strike time where most real paid projects fail miserably. So do we really need project managers? Let's start with describing the verb 'manage'.

Clearly we need something to control or direct to manage it. Can we control the projects or can we direct them? Apparently not, but we can control and direct people! So project management is actually not a real fact at all but the team management is.

So how do we manage teams? First thing we need is a team to manage. Let's describe the 'team'.
Clearly a team does not mean just a bunch of people who is just standing next to each other. A team must be competing and working together! Just like the third meaning above if the group who is pulling the wagon is not moving the same direction then that would not form a real team.

So first we need to do is to form a real software team who will work, act and develop together which can be managed. So next question how do we manage a technical team?

Technical people love and respect great technical people, you need to be more technical than them. If you ask who I respected most in my whole my career, was someone who was much more technical than me. I could easily accept his decisions and happy to see him as a boss or manager. So want to control the team? Be technical, learn the technologies you are planning to use. Try to stay one step ahead but not just show off, the team will respect you if they know they can get your advise and trust what you say.

Don't start with overriding them. Be open to every approach, decision or idea. Give them space to prove what they think by a small project or prototype. Challenge different ideas, let each party to agree on the best one. Accept good ideas, never hesitate to step back from yours. If someone else has a better approach accepting his way does not make you weaker. It just means he had a better solution but you are wise to see his approach is good. If you just override for the sake of keeping control in hands you will only lose respect.

The leader may need to give up some of his technical work hours to keep the team away from non tech details. The leader needs to be a leader not only be respected but also be trusted. The best way to achieve this status is to keep developers free of non technical duties and knowing them you will handle management pressure and their non technical problems. The more the team knows you are putting yourself between them and management to watch their back, they will watch your back! You may be surprised how tight and even impossible deadlines can be achieved if you are working with a bunch of friends who trying to watch your back instead of just professional developers. If the team doesn't want to log work and the management asks for it, either make the management accept it or do it on your own. You will be surprised how the team will fight back for you either keeping the deadlines or start logging. Just make them see you are there for them.

If you will be responsible for a team, it would be best if you hire that team which may not be possible most of the time. Still if you have any chance to meet, interview or decide who is going to be hired, take your part. I have seen lots of examples where non technical people hiring technical people and ask the team to work with them. Try to be a part of the hiring process and also let other members of the team join you. Let the team decide who they want to work with not the managers!

It is best to work with the best team but you can't always have a choice. If possible work with the best, if not it is ok. Each project will have different needs and roles, just try to give responsibilities according to the skills and interests. You can easily find something suitable to someone which would let other engineers to work more efficiently while getting input from everyone. One of the best team I ever been in had different level of engineers. Yet we could always find a way to split responsibilities and keep everyone busy and engaged. Good engineers don't like the repeated works and not so good ones may find it hard to invent new stuff, just do a fair share.

Next make your team feel special, for working with you and with each other. You probably may have heard how Steve Jobs canibalized Liza with the team of pirates he formed for the macintosh team. Although I have never been a fan of competition in a team, it is great when its between teams. Make your team feel special like the pirates of Jobs, let others see how you and your team feel special. One of the best team I worked with, we used to call ourselves as the A team, we designed special tshirts for the whole team and let everyone in the company know how good we were and enjoying what we do. Basically what we were doing was just a simple web app.

Being professional is not enough, be friends with the team. Go out drinking, or talk on not work related stuff. Want them to talk about their problems? You talk about yours first and once they do, try hard to help them. Who would watch your back? a friend or a perfect professional. A great developer may just stop delivering his work if he is not happy with management but a friend would not do that just not to put you in trouble. I have seen several examples where a developer was about to leave but still delivered his best just to help his friends in the team.

Still not convinced and believe the projects needs to be managed to get estimations and decide on timelines? First if you already have solid deadlines in your or management's head and not even consider team's estimations, please just cut the crap and don't even ask for estimations!
Else just let the team prepare a queue of tasks (sure you/they can use scrum way of backlogs, poker games...). Let developers to make estimations, preferably just units not time. Let them deliver tasks on intervals like sprints. Try to have working prototypes as much as possible. Start with pen and paper wireframes, working mockups, half functional products and let everyone see what is working.

Don't just put developers under ruling of someone filling an excel sheet or drawing bars on microsoft project and expect them to accept they will be paid less and respect him/her. Instead find or be a technical leader for the team which the team will respect the fact he/she should be paid more than them.