3 Reasons Why Java Is The Future Of Big Data, And The IoT

While Java’s been around for a little over 20 years, Big Data has only been a buzzword in corporate environments for a little over 5 years. While the concept has existed much longer than that, the majority of us hadn’t heard the word. Because it’s so new to so many of us, the term “Big 
Data” is still evolving, and can mean different things to different people.

To most people, the term describes any voluminous amount of structure data that can be used, mined, or better understood for information or intentional use.

“The rate at which we’re generating data is rapidly outpacing our ability to analyze it,” Professor Patrick Wolfe, Executive Director of the University College of London’s Big Data Institute, tells Business Insider. “The trick here is to turn these massive data streams from a liability into a strength.”

According to Antonio Regalado, Senior Editor for the MIT Technology Review, because of the sheer volume of data being being created, only about 0.5% of all data is ever analyzed. With this problem in mind, it’s no wonder developers are working around the clock to increase our computation capacity to understand and translate this vast amount of data into actionable insight.

With the amount of data we produce projected to continue its torrid, exponential growth, the need to analyze that vast amount of data will only continue to increase as well.
The gold standard in batch computational computing power to this point has been Hadoop, a free, java-based programming framework sponsored by the Apache Software Foundation that’s capable of processing large amount of data sets. With the past predicated on Java, it’s no wonder Java is expected to be the gold standard of big data and the Internet of Things for the foreseeable future.

  1. The big guys are turning to Java

    When Facebook speaks, the rest of the tech community listens. Running with the likes of Apple, and Google, Facebook has been on the main-stage of technology development for over ten years. In a recent statement about the future of their mobile app, Facebook has completely ruled out a return to HTML5, and is dedicating their future to its own Reactive Native, JavaScript framework.

    Originally reported by The Register, Facebook’s Director of Developer Infrastructure, David Mortenson, said the company will focus its mobile application development exclusively on the open-source React Native JavaScript Framework.

  2. 3 Great collection of open source libraries

    With its roots deeply engrained in open-source communities, a huge benefit to using Java is the amount of publicly available code that already exists. Companies like Apache, Google and other industry giants have even contributed to these vast libraries of code and information. With the amount of readily available code for use by anyone who needs to use it, the Internet of Things’ early development will benefit greatly from this already vast expanse of information and knowledge.

    It’s never a bad idea to search for a functionality code in Google, before writing it for yourself. After 20 years, there’s a pretty good chance that it’s already coded, tested and available for use.

  3. Java is everywhere already

    Java’s already on desktop, mobile, tablet, PC and Mac, and so are the programmers and developers who make it happen. Not only that, there’s also surging popularity in learning how to code Java. This abundance of information and thirst for learning it is why a lot of organizations prefer to choose Java for the development of apps over any other language.

    Its relevancy on every platform combined with the abundance of open-source code Java currently available makes Java one of the most in-demand skills now, and in the future.

The future of data analysis is, unequivocally, Java.

Accessibility: android vs apple

Those of us using mobile devices alongside a visual impairment are in a much better position than even 10 years ago. For a long time there was only one
game in town when it came to accessible phones, but Talks and Zooms from Nuance were only available on a limited range of handsets from one manufacturer.
It wasn’t perfect but at least it was there.

And then there was Apple. The introduction of the iPhone 3GS and iOS 3 in 2009 brought with it a whole new way of working with what was becoming the most
popular handset on the market. Four iterations later and the Apple model is holding strong and seems to be the de-facto choice for anybody with sight-loss.
But there is a strong alternative which brings with it a range of further options to choose from and decisions to make.

Most people have already made their choice (or had it made for them), but with new Android-based handsets being released all the time and a new iPhone
on the horizon, now might be the ideal time to see what the two main sets of accessibility can and can’t offer before you make your next purchase. This
piece is aimed mainly at visually impaired and blind users but may also be of use to people who just want something that will make their phone or tablet
use a little easier.

Let’s Begin

First of all, let me set out my position. I am visually impaired but I have what some would call ‘useful’ sight. I use magnification generally when I’m
in one place, and screen readers when I’m on the move or want to work in public without being nosed at! I use Apple iOS 7.1 on an iPad Air and iPhone 5.
I also use Android 4.3 on a Samsung Galaxy Note 3. In this article I will give an overview of both options and leave it to you to decide. I wont give you
a detailed guide on how to use individual features (these are numerous and can be found easily). The information is also based on using an unrooted/non-jailbroken
device, so that no additional tech knowledge is necessary. It covers

Screen Readers


Speech and Magnification Combined

Accessibility for non-disabled users

1. Screen Readers: Apple’s ‘VoiceOver’ and Android’s ‘TalkBack’

Let’s go from the beginning; both screen readers can be activated “out of the box”, because the option to enable them is present as part of the setup procedure.
This means that – on iOS at least – you can switch on and set up totally unassisted (for TalkBack, sighted help may be needed solely to activate speech).
In addition Apple accessibility settings can be configured from a connected computer via iTunes.

General Settings

Once you’re up and running, the settings for both systems can be found within sub-menus. Shortcuts exist for toggling speech on/off without having to leave
your current screen, but a big difference is that the VoiceOver Rotor can be used to quickly fine-tune settings (language, volume, typing mode etc) from
anywhere, whereas many of the TalkBack settings can only be tweaked from within its menu. Talkback has a comprehensive tutorial to teach gestures, notifications
and options. VoiceOver includes brief guidelines and a practice area where you can make ‘dummy’ gestures which are spoken to you without affecting the
app or device. This will give you a fair grounding in the basics but for both systems the only way to get familiar and proficient is practice. Sorry!

User Interface

VoiceOver and TalkBack offer much the same in the way of actual use; swipe a finger left, right, up or down to navigate the screen elements, text or graphics.
Double-tap a finger to make a selection. You can also easily read a page by character, word, sentence, paragraph or even the whole screen at once.

Both can provide feedback via pitch-changes (to differentiate between a highlighted keyboard character and one that is entered) and overall they are well
up to the job. They also make use of “contextual menus” in order to make changes to the way you read and manipulate text in different settings, so you
will get different options depending on the app you’re using (or even your current position within the app). Interestingly enough, Talkback has the option
to only read aloud the content of secure fields when earphones are connected, whereas iOS will always speak the character you just entered. If you’re likely
to be using more than one Android device (or want to be able to use a friend’s one without too much fiddling)) you can import and export your settings
for quick transfer.

Voice and Language

As with most screen readers, voice characteristics can be customised in both systems to give a range of language, quality, speed and verbosity. The range
of voices, genders and bit-rate vary but Talkback allows additional TTS (text-to-speech) language data to be downloaded at will. Voice package updates
are also released by Google separately to the periodical operating system updates.

Screen Blanking

Screen-reader users are familiar with the puzzled looks that sighted people have when they encounter a computer being used with a blank display, and this
feature already extends to the mobile world. VoiceOver’s ‘Screen Curtain’ blanks the display without otherwise affecting the phone use. This is an excellent
option particularly as reading personal or sensitive data in public may take a sight-impaired person significantly longer than usual. Android doesn’t have
any form of screen-blanking for its software, and although the screen brightness can be reduced, this is not a reliable substitute as the brightness on
a phone or tablet never truly reaches 0%.


VoiceOver makes extensive use of mutli-touch flicks, taps and twists for its interface, while most of Talkback’s gestures involve a single-finger tap,
flick or right-angle movement. The VoiceOver model means that a wide variety of commands can be accessed quickly (from starting/stopping music to re-labelling
a screen element). Talkback’s single-finger method might make it easier for use by those with reduced motor or mobility function, although ‘split-tapping’
in VoiceOver allows both hands to be used as an alternative. Talkback’s single-finger control also means that the device’s standard multi-finger gestures
(such as pinch-to-zoom) still work while it is running. Thankfully when you switch your device off, both screen-readers will automatically start up when
you power on (as long as it was on before!)

2. Magnification: Apple’s ‘Zoom’ and Android’s ‘Magnification’

These programs allow for magnification of all or part of the device screen (I know!) Both can be run invisibly, so ‘standard’ device usage can take place,
and at any time a single gesture will invoke magnification temporarily or permanently. While magnified, the screen can be panned in order to see other
areas, although this is achieved more easily depending on the size of the device screen (and your fingers!)

General Settings and User Interface

Magnification is less complex than screen reading, therefore options are relatively straightforward. You’ll need to be able to get through the menus in
standard view to activate, but after this you can set a fixed magnification factor which the screen will zoom to/from whenever you perform the gesture
(Android uses a single-finger triple-tap while Apple opts for a three-finger double-tap).

While performing this gesture you can keep your finger(s) on the screen to make fine changes to the magnification factor. Zoom fixes the new level once
you lift your fingers. Android Magnification allows you to temporarily magnify, pan and change the zoom factor all in the same sequence. Changes to the
zoom factor on both systems are very smooth and you can move the focal point using two or three fingers. Standard gestures such as pinch, flick and swipe
still work while magnified and with Zoom, touching an edge or corner of the screen will scroll the zoomed area in that direction (horizontally, vertically
or diagonally).

Key Points

Zoom retains your magnification factor at all times until you deactivate or change it manually. This includes lock screen and keyboard entry. Android Magnification
returns to zero magnification upon changing app, so you have to perform the magnification gesture again if you want to continue zooming. Although this
may seem silly, it does give you an overview of the screen before you decide where to zoom. Neither system retains the magnification factor when the device
is restarted.

Android Magnification has the option to split the screen during text-input. This means that the edit box can be magnified while the on-screen keyboard
remains standard. This is great when typing text although you will need a good grasp of the keyboard layout. Although Zoom retains your setting while changing
apps, it magnifies without discrimination so for example you can’t easily enter text using the on-screen keyboard as this is magnified along with the rest
of the display. On Android can also use text-prediction and drag-typing while magnified.

Speech and Magnification Combined

Some low-vision users want to use magnification with speech as a backup (or vice-versa) and both manufacturers’ systems allow for their screen reader and
magnification to run simultaneously without any problem. When this is happening, gestures for each program are effectively combined so a single-finger
flick right will speak the next item and a two/three-finger drag will move the zoomed area.

VoiceOver changes the display focus to the area currently being read, so if you are performing a continuous read the screen moves to each section as it
goes along. Android retains the magnified area of the screen even if you change the Talkback focus.

Another thing to note is that VoiceOver makes slight changes to the gestures if you run it with Zoom. Normally a three-finger double tap will toggle speech
and a three-finger triple-tap will toggle the Screen Curtain; with Zoom activated the double-tap toggles the zoom factor and the speech and screen curtain
options require an extra tap each to work.

Accessibility for non-disabled users

Although created specifically for disabled users, some Apple and Android features can be used by those with no ‘formal’ additional need, simply to make
things a little easier. A screen-reader is unlikely to fall into this category but options to enlarge fonts, reverse the colour scheme or make gestures
easier to perform (eg by voice or with only one finger) have numerous applications for many. Apple and Android include all these options, so a light-on-dark
display or the ability to turn an e-book into a talking book is very handy (and most people don’t know they already have it!)

While writing this, I received a firmware update for Android KitKat (version 4.4.2) which includes options for closed captioning on video clips. I haven’t
had an opportunity to test this yet but again, it may prove to be a useful option for ‘standard’ device users as well as those with impairments.

So, What’s The Choice?

Short answer: it’s up to you. For many it will come down to what is familiar. I’ve heard lots of people say that “this system is easy” or “you don’t want
to go with that one”, but like anything else, it’s only easy if you already know what you’re doing.

Some things to bear in mind when choosing:

VoiceOver/Zoom gestures are fixed and universal so moving from one device to another is seamless. The same applies to Talkback but it also gives you some
control over which gesture is assigned to which command

A number of companies make Android devices and they come in a range of system configurations and sizes. They may offer options such as connection to/controlling
TVs etc.

All iPhones and iPads have the same basic layout so when you pick one up you immediately know what bits do what

Depending on the manufacturer, Android devices have greater potential for expansion and upgradability, whereas all Apple devices are fixed and not easily

Apple has a more widely-established user base, and support will always come from one unified point

Keep in mind the level of compatibility between screen-readers and apps. With both systems you can add or change a label

Parcelable vs. Java Serialization in Android App Development

Android developers often face a predicament while passing object references to activities of whether to go with the Java Serialization method or opt for
Android Parcelable. This blog is my attempt to compare the two techniques and cite an example to help decide which one of these is the best approach for
passing an object from one activity to another.

Passing primitive data types like string, integer, float, etc. through intents is quite easy in Android. All you have to do is put the data with unique
key in intents and send it to another activity. If a user wants to send Java objects through intent, Java class should be implemented using the Parcelable
interface. Serialization, on the other hand, is a Java interface that allows users to implement the interface which gets marked as Serializable.

During the Android application development process, developers often have to send Java class objects from one activity to another activity using the intent.
Developers can opt from the two types of object passing techniques, i.e. Serialization and Parcelable of object.  The fact that Parcelable is faster than
Serialization makes it a preferred choice of approach while passing an object. Here’s why:


Android Parcelable implementation allows objects to read and write from Parcels which can contain flattened data inside message containers.

If a developer wants to convert a Java object into Parcelable, then the best way to do so is by implementing the Parcelable interface and overriding the
writeToParcel() methods in its own class. The first step is to override the writeToParcel() method and  write all object members into parcel objects. The
second is to create a static Parcelable.Creator object to de-serialize the Java object.

Differences between Serialization and Parcelable

Parcelable and Serialization are used for marshaling and unmarshaling Java objects.  Differences between the two are often cited around implementation
techniques and performance results. From my experience, I have come to identify the following differences in both the approaches:

·         Parcelable is well documented in the Android SDK; serialization on the other hand is available in Java. It is for this very reason that Android
developers prefer Parcelable over the Serialization technique.

·         In Parcelable, developers write custom code for marshaling and unmarshaling so it creates less garbage objects in comparison to Serialization.
The performance of Parcelable over Serialization dramatically improves (around two times faster), because of this custom implementation.

·         Serialization is a marker interface, which implies the user cannot marshal the data according to their requirements. In Serialization, a marshaling
operation is performed on a Java Virtual Machine (JVM) using the Java reflection API. This helps identify the Java objects member and behavior, but also
ends up creating a lot of garbage objects. Due to this, the Serialization process is slow in comparison to Parcelable.

I ran a test and here are my findings:

Intent intent = new Intent(ParcelableActivity.this, RegistrationSuccessActivity.class);
/// for Parcelable list
intent.putParcelableArrayListExtra(“data”, pacableArray);
/// retrieve in another activity
RegistrationPogo registrationPogo= getIntent().getParcelableExtra(“data”);
package com.threepillar.bestpractice.ui;
import Java.util.HashMap;
import Java.util.LinkedHashMap;
import Java.util.Map;
import Android.os.Parcel;
import Android.os.Parcelable;
import Android.widget.EditText;
public class RegistrationPogo implements Parcelable {
String firstName = “”, lastName = “”, emailAddress = “”, phoneNumber = “”,
city = “”, state = “”;
int zipCode;
HashMap<string, String> mapRegData = new HashMap<string, String>();
public HashMap<string, String> getMapRegData() {
return mapRegData;
public void setMapRegData(HashMap<string, String> mapRegData) {
this.mapRegData = mapRegData;
public String getFirstName() {
return firstName;
public void setFirstName(String firstName) {
this.firstName = firstName;
public String getLastName() {
return lastName;
public void setLastName(String lastName) {
this.lastName = lastName;
public String getEmailAddress() {
return emailAddress;
public void setEmailAddress(String emailAddress) {
this.emailAddress = emailAddress;
public String getPhoneNumber() {
return phoneNumber;
public void setPhoneNumber(String phoneNumber) {
this.phoneNumber = phoneNumber;
public String getCity() {
return city;
public void setCity(String city) {
this.city = city;
public String getState() {
return state;
public void setState(String state) {
this.state = state;
public int getZipCode() {
return zipCode;
public void setZipCode(int zipCode) {
this.zipCode = zipCode;
public int describeContents() {
// TODO Auto-generated method stub
return 0;
public RegistrationPogo() {
public void writeToParcel(Parcel dest, int flags) {
// TODO Auto-generated method stub
final int N = mapRegData.size();
// dest.writeInt(N);
if (N > 0) {
for (Map.Entry<string, String> entry : mapRegData.entrySet()) {
String dat = entry.getValue();
public static final Parcelable.Creator CREATOR = new Parcelable.Creator() {
public RegistrationPogo createFromParcel(Parcel in) {
return new RegistrationPogo(in);
public RegistrationPogo[] newArray(int size) {
return new RegistrationPogo[size];
private RegistrationPogo(Parcel in) {
firstName = in.readString();
lastName = in.readString();
emailAddress = in.readString();
phoneNumber = in.readString();
city = in.readString();
state = in.readString();
zipCode = in.readInt();
final int N = in.readInt();
for (int i = 0; i < N; i++) {
String key = in.readString();
String value = in.readString();
mapRegData.put(key, value);

Speed Testing Results

In this example, Android Parcelable came out to be faster than the Java Serialization technique. One of the main reasons was the fact that Parcelable is
fully customizable, allowing developers to convert required data into Parcelable. Serialization is a marker interface as it converts an object into a stream
using the Java reflection API. Due to this it ends up creating a number of garbage objects during the stream conversation process. So my final verdict
will be in favor of Android Parcelable over the Serialization approach. I have tested both performances on HTC Desire, Nexus 4 and Samsung Galaxy S3 devices.