Category: Mobile Development

The below blog contains mainly about the mobile development. Having an App within an App known as Alpha App.

Alpha App – App within an app

In today’s busy world everything has become compact in the form of mobile application aka app and has summoned the entire world in hands of the phone owner. The motive of every app owner is to keep its app user engaged on their respective app all the time. Basically, the more screen time the app gets the better. Many social networking apps are successfully engaging their users actively throughout the day. But a good app is the one that is able to take care of every need of its user including non-social ones.

It would be a compact world if a user could launch an app that would perform all his tasks in one place. That would be like a genie in a bottle which would book your taxi, order food if you are hungry, book hotel for you, buy movie tickets for weekends, check- in for a flight, perform complex banking transaction, book a doctor’s appointment when unwell, pay an electricity bill, meet a stranger around you, chat with your friends, read magazine articles, shop online etc. All in all a single integrated app so the user need not fidget around with many apps. An app within an app, technically an Alpha app.

Alpha apps act as an entry point to do anything on your phone. There are certain points need to be taken care of  while developing an alpha app.

1.User Interface.

2.Exposing API.

User Interface : The external system sends data which has got generic protocols, on the basis of that dynamic UI rendering performed. It’s difficult to decide which  component is required to be rendered at the run time.

Exposing API : The most important use of API is providing a service that other people, whether business or individual, can use and pay for, as in the case of cloud services where you pay-as-you-use. Exposing API is the future where many different apps can integrate the services provided by the API of a particular business.

Wechat is the first Alpha app in China which does all the tasks. It provides all the services from booking a taxi to paying your bills from the app, payment modules etc. Uber has already announced the public release of its API, allowing major mobile applications as well as individual developers, to integrate Uber offering into their platforms.

will write more about this in the next blog…

XAMARIN From a newbie’s perspective

Coming from a conventional web app world, the world of mobile always fascinated me. However, I always felt like a misfit there because of dot net world’s obvious limitations in mobility.

I had read about Xamarin sometime in early 2014 and it instantly grabbed my interest, and I patiently waited for a Xamarin opportunity to come my way.Xamarin sometime in early 2014 and it instantly grabbed my interest, and I patiently waited for a Xamarin opportunity to come my way.

So, the moment I was presented with a chance to work on Xamarin, I just couldn’t wait for a second and decided to take the plunge.

Xamarin seemed like a very attractive option for .NET developers to be able to create mobile apps with minimum learning curve,  leveraging .NET framework to its fullest.

However, after actually taking the deep dive, I figured that although you do feel at home with the entire .NET similarity in the environment, it’s not just .NET that would ensure a smooth sail.

There is a substantial learning curve involved with Xamarin, having come from a non-mobility background. One additionally needs to acquire the knowledge of basic native mobile application development concepts.

However, the following features in Xamarin studio makes one life much easier compared to the other mobile app development suites –

1. Look and Feel : Xamarin leverages the native look and feel of iOS, Android Studio as well as Visual Studio, which gives it an edge over the other native competitors.

2. Cross-platform Support: Xamarin Forms largely follows the write-once-run-anywhere philosophy where you could write your business logic and database code in common utility classes and reuse them across your iOS and Android apps.

3. Impact on regular development time : You substantially save on the development time when you write code that could be re-used by multiple platforms, with only the UI to be re-created.

4. Xamarin is fully native: Contrary to PhoneGap or Cordova or the likes, Xamarin is fully native; meaning that Xamarin’s bindings on any given platform mirror the native calls so closely that if you know the API, you can easily find its equivalent Xamarin, with very few exceptions. Xamarin also compiles its code to native c# code.

In the end, it all comes down to what your current project requirement is, and whether Xamarin fits well into the entire scheme of things and also, the skill set of the programmers at hand.

WhatsApp with UIActivityViewController for sharing image

Hello, iOS buddies!! You might have come across a situation where you want to provide share option to the user in your application to share (Image + Text data).
Your best bet would be to use UIActivityViewController where you have to just pass items to share and appropriate application will be shown in sharing option.
But when it comes to WhatsApp, you can either pass just text or just image but not both. This is due to the limited support from WhatsApp for custom URL scheme on iOS:
Whatsapp FAQ

So, in this case, if you are passing image + text data using UIActivityViewController and if the user selects WhatsApp, only the text data will be sent and not an image.
For sending an image to WhatsApp, we need to use UIDocumentInteractionController.

Workarounds for this:

1)
Detect if a user selected WhatsApp application and use UIDocumentInteractionController to copy an image and send it to WhatsApp. This will open WhatsApp twice, and would not be a pleasant experience to the end user.
But if your sharing requirement includes sharing of data+image and image is the priority this is the best alternative.
Please note in this option, only an image will be sent to WhatsApp and not text.

2)
If Whatsapp is the priority for sharing image data, you can use UIDocumentInteractionController for sharing and not UIActivityViewController.

Please find below the sample code written in swift to detect if user selected WhatsApp for sharing and triggering UIDocumentInteractionController for user to allow WhatsApp from available option:


@IBAction func shareClicked(sender: AnyObject) {

            let objectsToShare = ["[\(self.productDetail.code!)] \(self.productDetail.name!)", productImg]
                let activityVC = UIActivityViewController(activityItems: objectsToShare, applicationActivities: nil)
                
                activityVC.completionWithItemsHandler = { activityType, success, items, error in
                    if !success {
                        print("cancelled")
                        return
                    }
                    
                    if activityType!.rangeOfString("whatsapp") != nil{
                        print("whatsapp")
                        
                        let directoryURL = NSFileManager.defaultManager().URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask)[0]
                        
                        let localPath = directoryURL.URLByAppendingPathComponent("whatsAppTmp.wai")
                        UIImageJPEGRepresentation(productImg, 1.0)?.writeToURL(localPath, atomically: true)
                        
                        self.docController = UIDocumentInteractionController(URL: localPath)
                        self.docController.delegate = self
                        self.docController.UTI = "net.whatsapp.image"
                        self.docController.presentOpenInMenuFromRect(CGRectZero, inView: self.view, animated: true)
                        self.docController.presentOpenInMenuFromRect(CGRectZero, inView: self.view, animated: true)
                    }
                }
            
                self.presentViewController(activityVC, animated: true, completion: nil)
            }
 

Following delegate method is required to be implemented in your controller for providing a view controller for presenting a document preview:

func documentInteractionControllerViewControllerForPreview(controller: UIDocumentInteractionController) -> UIViewController {
        return self
    }

Feel free to contact javal@idyllic-software.com for any queries or connect on linkedin

How to set onClick in ListView Item?

Hello, fellow android developers!!! This post is meant related to a problem which I feel is most common when using custom list item.

You might have come across a situation where you have Button/ImageButton inside your list item and
you want to handle the click event of that button and the list item separately but cannot achieve the event for the list item click in any of following methods:

setOnItemClickListener on ListView
setOnItemSelectedListener on ListView
setOnClickListener on each ListView Item.

The reason being you have other clickable/focusable components inside your list item which receives focus instead of a list item.
For example, your layout for list item looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/rounded_corner"
    android:padding="10dp"
    >

    <TextView
        android:id="@+id/feed_text"
        android:focusable="false"
        android:focusableInTouchMode="false"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:paddingRight="20dp"
        android:paddingBottom="5dp"
        android:maxLines="2"
        android:text="pasdfa asdfasdf wer asdfasdf2 rwafasdfasd fasdfwerasdfasdf"
        android:ellipsize="end"
        android:maxLength="140"
        android:textSize="14sp"
        android:textColor="@color/menu_text_color"/>
        
		<LinearLayout
			android:layout_below="@+id/feed_text"
            android:focusable="false"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:orientation="vertical"
            android:layout_weight="1"
            android:gravity="center_horizontal">

            <ImageButton
                android:id="@+id/upvote_button"
                android:focusable="false"
                android:focusableInTouchMode="false"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:background="@drawable/upvote_state"/>
            <TextView
                android:focusable="false"
                android:focusableInTouchMode="false"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:textSize="10sp"
                android:paddingTop="5dp"
                android:text="UpVote"/>
        </LinearLayout>
 
</RelativeLayout> 

Here you have an ImageButton inside the list item which will consume the click event and the click listeners for list item will not be called.
To solve this issue set the descendantFocusability of the parent of ImageButton to blocksDescendants. This will block all descendants (elements) of that view group from receiving focus.
The updated layout will be as follows:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/rounded_corner"
    android:padding="10dp"
    >

    <TextView
        android:id="@+id/feed_text"
        android:focusable="false"
        android:focusableInTouchMode="false"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:paddingRight="20dp"
        android:paddingBottom="5dp"
        android:maxLines="2"
        android:text="pasdfa asdfasdf wer asdfasdf2 rwafasdfasd fasdfwerasdfasdf"
        android:ellipsize="end"
        android:maxLength="140"
        android:textSize="14sp"
        android:textColor="@color/menu_text_color"/>
        
		<LinearLayout
			android:layout_below="@+id/feed_text"
            android:focusable="false"
            android:descendantFocusability="blocksDescendants"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:orientation="vertical"
            android:layout_weight="1"
            android:gravity="center_horizontal">

            <ImageButton
                android:id="@+id/upvote_button"
                android:focusable="false"
                android:focusableInTouchMode="false"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:background="@drawable/upvote_state"/>
            <TextView
                android:focusable="false"
                android:focusableInTouchMode="false"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:textSize="10sp"
                android:paddingTop="5dp"
                android:text="UpVote"/>
        </LinearLayout>
 
</RelativeLayout> 

Feel free to contact javal@idyllic-software.com for any queries or connect on linkedin

Don’t use up your user’s device storage space

Hello, fellow developers!! This article is for iOS developers on how to give a better user experience and more control over the app to its users.

These days, most API-driven applications do have some/large amounts of media content, whether it’s an image or a video. And to give the user a better experience of not downloading the content each time, we tend to cache the content with the most images by using various Image Caching libs available. Now, it often happens that most of the content being cached become outdated due to various reasons like an image is updated for the same content or the content is too old that the user is not revisiting it within the app. But, in most cases, this cached content is never cleared and it keeps on growing, thus utilizing more and more space on the user’s iPhone unless you have integrated some sort of mechanism to clear it automatically or provided some kind of way to the user for clearing it.

Due to all this, your app size becomes a lot larger than its size in the store. Now, as you all know iPhone does not have an inbuilt way to clear the cache, like what is available on Android. So, the user does not have a way to reduce the size of your app and clear up some of the device storage space. This introduces the risk of a user deleting your app by seeing the amount of space it is utilizing when a user tries to manage storage for clearing some space.

And even if iPhone had the clear cache option, it is still a good move to provide a user a way to clear selective media if they don’t want to delete the entire cache.

So, it’s always better to give the user more control over your app so that he may have better visibility of your app and so that he won’t keep wondering why the size shown on the app store is a lot more than what the installed app is occupying.

One good example of this is the Whatsapp application. Whatsapp provides an option to view media from where a user can selectively delete the downloaded media. Although they don’t have a user-friendly alternative way to clear entire cache content, they do provide a way for the user to clear some storage by deleting the unwanted cached media.

So, if your application is having extensive media content that is getting cached, it’s always good to provide some option to the user from where they can clear the cache whether the option is within the app or in the app settings.

This will help your user to stay engaged with your app by having better control over your app and they will not simply delete it to clear some amount of storage space on their device. And believe me once a user deletes the application, chances are very less that they will re-install it.

So, keep your app users happy by giving them more control over the app content.

Feel free to contact javal@idyllic-software.com for any queries or connect on LinkedIn

Dynamic handling of strings/text for Mobile apps – Part 2

In my previous post (Dynamic handling of strings/text for Mobile apps – Part 1), I discussed some issues with hard coding labels and text. This post deals with solutions to those problems and involves a method that provides more flexibility by updating text dynamically.

Please note: This is not to be confused with the localization of the app. But, this approach can be used for the localization purpose also.

This approach involves maintaining a strings file on the server instead of hardcoding it in the app.

Following are the steps to follow for the implementation of this approach:

On Server Side:
– Maintain strings file XML / JSON on the server. Its better to use JSON if the person who will be maintaining the file is aware of JSON structure and can validate json after any change. Otherwise in a normal scenario, we can keep it in XML format for ease of update and maintenance even by a non-technical person.

– Maintain a version number of this string file into config / settings XML. In most applications, we have one config file from the server which downloads app related configuration. If your application does not follow the config file structure, you can maintain the app version and send it as a query parameter, along with other API response. This would be troublesome to handle if your app does not handle response at a single place. Its always better to introduce a config XML for the app which can maintain config related data for e.g. latest version of this strings file.

On App Side:
App architecture needs to be implemented as mentioned below to incorporate update of strings file from the server.

– Maintain the local version of strings in localizable.strings (iOS) file / strings.XML (android). This local version is still required in case app fails to retrieve strings from the server which can be one of the following reasons: invalid XML format, file not found, time out.

– App will always pull config file when the application enters the foreground state. Then app will check version number of strings file with local version number ( local version can be cached in NSUserDefaults for iOS or in SharedPreference for android). If version number from server is not equal to that of local, app will go ahead and download latest strings file from server and write it to user defaults or to file. Also, update the local version number for the strings file to that of the latest version number from the config file once the download of strings from the server is successful. Now, it is mandatory to write and store this strings file response from the server. You cannot just store it in memory and read from there, the reason being, strings file can be huge in size and can contain a lot of strings which results in more parsing time in case of XML format, so we don’t want to download strings file from the server every time. That is the reason we maintained the version number for it in the config file. Downloading config file each time should not affect the performance of app as config file contains fewer data as compared to strings file.
Also, convert this XML response to json and store it in the dictionary to keep it in memory.
It is recommended to store in a dictionary in order to achieve faster access and avoid frequent read from file / user defaults where the response is stored for future access. Also, it will be one-time conversion from XML to JSON at the time of download. Later on, it can be accessed simply as a key-value pair.

Note: App should download strings file in the background and should not block user as you already have a local version of strings so labels will never be empty. The app will reflect the changes whenever the user revisits the screen.

– Now, we already discussed how to fetch the latest version of strings file from the server. But, how to utilize it for displaying on labels?

– Write a utility function which returns value related to key passed to the function.
This function will first look into the local dictionary for the value. If a value is null or empty, look for the value corresponding to the key from localizable.strings(iOS) or strings(android) file. In this way, it will always return some value and should never be empty. For easiness of debugging, if the value is still not found, don’t return an empty string from the function. Instead, return the key itself as a value. This will help to identify that the value for the corresponding key is missing in the strings file on the server.

– Now, what if the next time, app comes to the foreground and there is no update of strings file from the server? In this case, the local dictionary will be populated with the last cached response from the server stored in user defaults / file. If the last cached data is not found, local dictionary will be null and by default, the utility function will pick a value from the bundled strings file.

– In this way, we can update strings to display on a label dynamically from server. Whenever there is a change in strings file, its version needs to be updated in config file else the app will not download the new file.

Now, on the developing end you will argue that with this approach, you cannot set the text directly into xib (iOS) / layout (android), and need to do it programmatically to always fetch from utility function with its associated key. To solve this problem, you can always subclass the label and override set text method to pull the value from utility method. Now, use this subclassed custom label on your xib file and set the key of the strings file as a text to it.

Sample Strings file:

<?xml version="1.0" encoding="UTF-8"?>
<strings>
<login_header_key>Login</login_header_key>
<login_description_key>Enter your six digit pin to login</from>
<submit_key>Submit</submit>
</strings>

– This approach just needs a one-time setup. Post-setup, it’s very easy to maintain without any dependency on the developer and does not require app updates.

– On the UI side, try to maintain labels and view, dynamic in size so as to properly display dynamic text length.

– The same approach can be used for localization also. Different language files can be maintained on the server and downloaded when there is a change in version. Also, the local dictionary can be populated with the appropriate cached response based on the current locale of the device.

Feel free to contact javal@idyllic-software.com for any queries or connect on linkedin

 

Dynamic handling of strings/text for Mobile apps – Part 1

It is a pretty common habit of developers to hard code labels and text directly into xib files or if they plan to localize, it is specified in localizable.strings files for iOS. For android, same goes into strings xml or some even hardcode into layout XML by ignoring warnings.

In most scenarios, the above approach is adapted for speedy development and with a misconception that there will be hardly any change for labels and headers or in case of any change, it would be a minor one that can be easily fixed.

But in adapting this, developers usually don’t consider the following things:

1) Difficulty in finding out where the text is displayed.

There are chances of other developers taking over the project, in which case it will be tough and time consuming for them to figure out the place from where the text has been set. It is not always the case that UI components can be easily found by searching its relevant xib (iOS) and layout (android) files. In some scenarios where the UI is generated dynamically, it becomes difficult to figure out from where the text is getting displayed.

2) Text changes after the app goes live.

Often it happens that, after the app goes live, the client turns up to change some text here and there which they found is not correct or there might be some typos that went unnoticed. In this scenario, if the strings were hard coded within the app, it will require an app update just to change the text. And normally big organizations don’t go for frequent app updates unless there is a blocker issue. In this scenario app will reflect wrong spelling / incorrect text till the time when there is a specific requirement for the new version to be uploaded. And in case of iOS, even the app approval time needs to be taken into consideration, which will delay the change being reflected by a week or two.

3) Maintaining consistency between different platforms.

If your app is supported on more than one platform, it can happen that text or error messages are different in iOS as compared to those on android for the same functionality. This would be a bad user experience and will affect client impression in the consumer market.

To avoid issues like these, there is an approach to handle text displayed on the UI for iOS / android app, from the server side, which provides flexibility to update it dynamically and does not require app version upgrades just for some copywriting correction.

To know more about this approach, be sure to check in on us in a couple of days when I’ll be posting a solution for the issues listed above.

Edit: Here’s Part 2 which talks about how I deal with the above issues! Dynamic handling of strings/text for Mobile apps – Part 2

Subscribe To Our Blog

Get access to proven marketing ideas, latest trends and best practices.

Next up home

Contact

Lets build cool stuff

Share your contact information & we will get in touch!

I want (Tell us more about your dream project)