Tuesday, January 7, 2020

About Me

1. Full Name (No Abbreviations): Abhinav Saxena
2. Email ID: abhsax130778@gmail.com
3. Mobile: 9818595272
4. Date of Birth: July 13th, 1979.
5. Current Organization Name & (DOJ): Coineption, April 31st, 2018.
6. Total Experience: 15+
     Team size you are leading currently: 10
7. Relevant Experience on:
            (a) Core Java:5
            (b) Spring: 3
            (c) Hibernate : 3
            (d) Web Services: 3
8. Current CTC (in INR): 7 LPA
9. Expected CTC (In INR): 8 LPA
10. Notice Period: Can join immediately
11. Current location: Noida
12. Open for Noida: Sure
13. Qualification: % scored in each:
(a) 10 %: 50%
(b) 12%: 50%
(c)  Graduation %: 50%
(d) Post Graduation %: 58%
14. Are you available for the Face to face interview Interview in Noida: Sure.
15. Ready for night shifts: Sure.
16. Ready for 6 days job.: Yes.

-- ONLINE PRESENCE --

Online Presence:-

Twitter:- @AbhinavSaxena3
https://www.twitter.com/AbhinavSaxena3

Facebook:- abhinav.saxena.566
https://www.facebook.com/abhinav.saxena.566

LinkedIn:- https://www.linkedin.com/in/abhinav-saxena-a63aa714

Tumblr:- https://www.tumblr.com/abhsax130778@gmail.com

---- BLOGS:-

https://mobi-app-dev.blogspot.com/?m=1
https://becominggrt.blogspot.com/?m=1
https://abhsaxprivpol130778.blogspot.com/?m=1
https://gr8lyr.blogspot.com/?m=1
https://abhinav-alexanderthegreat.blogspot.com/?m=1
https://abhs4smj.blogspot.com/?m=1
https://supremehymn.blogspot.com/?m=1

Saturday, July 20, 2019

How to have an efficient mobile application

For small businesses and big corporate companies alike, mobile is the latest frontier. Yet rather than simply developing a mobile-friendly version of your website or adding a cool e-commerce capability to the mobile user experience, more and more entrepreneurs are wisely delving into the mobile market by developing a smartphone app.

But not all apps are made equal — scroll through the Google Play Store or Apple app store and you’ll find countless offerings that are useless to users and a waste of money from companies. In fact, some apps actually make the businesses that produce them look worse to potential consumers than if they never put that app on virtual shelves.

While going through developing an application what most people forget is that with whom they are competing. On a closer look it is the similar application available on the play store or the application which are actually already residing on the user's mobile.

Designing a mobile app for your small business? Following should be a must have feature in the application

1. Feedback system

The importance of having some way for users to provide feedback on your app is critical. Whether it is a button or a link to open an email doesn’t matter; the important part is that you give your users a quick way to report bugs, and provide suggestions or criticisms. Users will appreciate knowing that you are open to their feedback and that their input can shape the future of your app.

2. Usability first

A compelling mobile application must feature an interface that focuses on usability. The best way to do this is to follow the general application hierarchy of widely used apps like Facebook, Instagram and Twitter. User experience bonus points are awarded if it is also beautiful and (pleasantly) surprising!

3. Can you customize?

Make sure that there is a clear way to adjust the settings for your app: colors, font sizes and, most importantly, privacy settings if it happens to be a social app. The more opportunities the user has to tailor the app to her own taste, the less chance that you will get something wrong. And, if you do, it will simply be adjusted by the user.

4. Keep it simple

It gets tempting to throw in a million small, frivolous features into your mobile app because you think they’re “cool” or good-looking, but don’t. Figure out the few basic things users want and build those couple features, and nothing else. I’d rather use an app that let me do what I want in 15 seconds than a convoluted UX that lets me do things I have no interest in actually doing.

5. Remember, it’s a phone

If you are a small business with a brick-and-mortar operation, I always recommend taking a step back and remembering the core function of a mobile device: It’s a phone. Including the ability for your customer to have an over-the-phone connection with you, while they’re interacting with your mobile application, can go a long way to delivering top-notch customer service.

6. Maintain relevance

The content in it must be something that is impossible to gain from your website. Stop building apps that are just big web browsers, and focus on pushing relevant information and delivering a richer experience that is beyond what your mobile website can do.

8. Ruthlessly eliminate clicks

If you must ask users to register, sign up, or fill out forms, be zealous about eliminating every possible click, or tap, from the design. Ask for less information. Conversion rates fall sharply when extra work is required to sign up. This is a mistake novice designers make over and over. You only have a short window to hook them, and if they have a bad experience, they won’t try again.

9. Don’t change!

When converting a traditionally browser-based system to a mobile app, make sure not to omit or hide any features, however ‘small’ they may seem. Nothing is worse than failing to find, on the mobile app, that one key feature that you always use on the browser version!

10. Include analytics

As a mobile app developer, one key component is to incorporate analytics into your mobile app. A small business must be able to track and identify their users experience and actions. Most users do not enjoy giving up their location, which is understandable. Tracking a users location is different to tracking and analyzing their expe rience. The data gathered will only help encourage better updates.

11. Offline capabilities

It’s frustrating to users when an app is entirely unusable just because they have a weak signal. Consider how you can build in content or interactivity that doesn’t rely on a wireless signal. It’ll make for a positive user experience while your users are on-the-go, online or off.

12. Go with gamification

Gamification allows users to be interactive and have fun while using the app. People will come back to an app again and again if it provides some kind of value, and short-term fun and competition are always winners.

13. Prioritize speed

It’s very important to make sure the app isn’t slow. People used to despise Facebook because of how slow the mobile app is. It is crucial that your app doesn’t make people wait around while it loads.

14) Geography

The geography or the location is a feature which comes into play when app is on role. Different geographies have different requirements and availability of ingredients required by the application. just in case of an example the Internet connectivity varies from region to region. Same is the cost that people can spend to avail Internet.

15) Memory and Internet Data usage 

The Memory consumption on phone being on storage or while the app is on play is one of the important constraints that has to be taken care of. The app requiring having large memory requirements are easily discarded. As the Internet connectivity plays as vital ingredient for apps to function, the amount of data usage done by the app is another thing that should not be forgotten.

Friday, March 1, 2019

How to use fragments ideally in Android Applications

My suggestion is: do not use activities at all, instead use fragments, and replace them in the container (Linear Layout for example) where you show your first fragment.

The code is available in Android Developer Tutorials, you just have to customize.

http://developer.android.com/training/implementing-navigation/nav-drawer.html

It is advisable that you should use more and more fragments in your application, and there should be only four basic activities local to your application, that you mention in your AndroidManifest.xml apart from the external ones (FacebookActivity for example):

1. SplashActivity: uses no fragment, and uses FullScreen theme.

2. LoginSignUpActivity: Do not require NavigationDrawer at all, and no back button as well, so simply use the normal toolbar, but at the least, 3 or 4 fragments will be required. Uses no-action-bar theme

3. HomeActivity or DashBoard Activity: Uses no-action-bar theme. Here you require Navigation drawer, also all the screens that follow will be fragments or nested fragments, till the leaf view, with the shared drawer. All the settings, user profile and etc. will be here as fragments, in this activity.
The fragments here will not be added to the back stack and will be opened from the drawer menu items. In the case of fragments that require back button instead of the drawer, there is a fourth kind of activity below.

4. Activity without drawer. This activity has a back button on top and the fragments inside will be sharing the same action-bar. These fragments will be added to the back-stack, as there will be a navigation history.

[ For further guidance see: https://stackoverflow.com/a/51100507/787399 ]

Happy Coding !!

Tuesday, January 7, 2014

Screen Management in Android, J2ME and BlackBerry

If we follow the following, we can give a good user experience.

1. As Android gives Fragments, (which was to manage the views in Tab devices mainly, I use it to reduce the number of Activities in the application), J2ME application should have minimum of two Displayables (Form, List, Canvas and GameCanvas) in the memory at a time, similarly minimum of MainScreen, FullScreen or PopupScreen at a time.

You can use IDs, and double buffering to repaint or show 'screens' on same displayable.

2. Keep minimum of Objects in the global objects, and remember to destroy them when no longer in use. So you must have onDestroy() for each 'screen' or 'fragments' you show in the view.

3. Use Adapter or WeakReference techniques to show the items in a list view; Pagination or Pull to Refresh techniques to show limited views on a View. Lazy loading to create and destroy the image objects once loaded in the SDCard memory from the network.

4. All the IOExceptions should be handled in a background thread as in AsyncTask in Android, and if the result is to be shown on the screen, use bundles to pass to it as a serialized object and update in the UI Thread. This feature is not in J2ME, but BlackBerry and Android have it.

5. In Android the concept of LocalBroadCast Manager can be used in communication between Services and Activities combining preferences. In BlackBerry you have GlobalEventManager and PersistentStorage, but you should transfer all the responses in both from IO Thread to another thread preferably a UI Thread, as the event manager should not wait, and to ensure proper UI refresh on the active screen. While there is a background operation, show a progress bar to prohibit user to cancel. If you want to use a cancellable progress bar, or if you can not prohibit user to do any action, cancel previous requests, using a Boolean isCancelled tracker.

6. Keep track of events like Swipe, Orientation Change, change in size of screen, device resolution adaptation, virtual keyboard show and hide, paused and resumed state of Displayable/MainScreen/Activity. All the recording of screen state should be done in a onPause() callback, and all the refresh activity in onResume().

7. There are design concepts for showing most of the contents in the same screen. Like you have Tabbed Panes, NavigationDrawer, ViewPager, ActionBars, Immersive mode, Context menus, 'SuperFish', 'Carousels', ScrollView and so on in Android. If these are properly implemented, gives user a comfortable experience.

Android Fragment Transactions

[Get most from Android developers blog]



Here are some tips that I follow now while using fragments in my activities:

First you would like to achieve something like this:

https://moqups.com/abhsax130778@gmail.com/lc0ZOERO/p:a5d7b55eb

Then there are scenarios like:

-----------------------------------------------------

Scenario 1:

1. Suppose there is a fragment on an activity and a button on it. You click on a button and another fragment opens.

2. From there, you press on back/return button and you come to first fragment.

That is easily done using back stack.

Now you want to do the same using swipe. I mean coming from second fragment to the first using the swipe and not the back/return button.

You usually do it with a backstack, while replacing the fragment 2 with fragment 1 in the transacton when opening fragment 2 from fragment 1:

    FragmentManager manager = ((FragmentActivity) this).getSupportFragmentManager();
manager.popBackStack();

---------------------
Scenario 2:

1. There are 4 tabs on action bar activity, and on each there is a fragment.

2. You click on a button on fragment 1 on tab one and it replaces with fragment 5 (while 2, 3 and 4 are on their tabs respectively).

you move to tab 2 and there is fragment 2, and when coming to tab 1, still there is fragment 5.

You left swipe on fragment 5 and come to fragment 1 remaining on tab 1 and this state is also maintained.

This you can do without transactions by having stack of fragments for each of the tab and pop when onBackPressed knowing what tab is active.

You do the same when the left swipe is detected.

[The stack for each tab is in another array arranged in the order of the tab displayed.
It updates the ViewPager adapter onClick and onBackPressed  thus maintaining the navigation history for each tab.]

So:

Effective management of transactions for fragment:
==================================================
[Note: In case you are using FragmentStatePagerAdapter, you can play with replacing a fragment with another fragment at a particular index in the list of fragment that you are using as a data for this adapter, in a way that you are in the same tab but its content is changed without changing the tab. Then use notifyDataSetChanged(). Here you do not use transactions, but otherwise you do].

1. Use Fragment.instantiate() to initialize your fragments instead of
constructor.

2. Use listeners to update/delete the reference of instance
(from the collection used to refer them) of fragment onCreateView and onDestroy.

3. Use getView() to get the root view of fragment every where and on update functionality.

4. Do not keep track of instances, in fact avoid static pointers where ever possible.

5. Use getSupportFragment instead of keeping reference of FragmentManager in view pager adapter or elsewhere.

6. Use attach detatch on transaction hide view, to get rid of child views on Fragment's root view and re initialize.

This is because only one fragment needs to be visible at a time, the others need to detach.
Therefore re-attach on demand.

7. getActivity() or getApplicationContext() whatever applicable, instead of keeping a global variable to keep references to context.

8. onConfiguration change (orientation, keyboard, resize): do in activity and pass it to active fragment which manages it.

Important: If you do want to use fragments for transactions, do not declare them in layouts.
Provide container (layout) id in add fragment transaction.

9. A Fragment transaction should be done in an event call, not anywhere else, and such an event should not be repetitive. This prevents Illegal Argument Exception.

10. There is a ViewPager method where you do not have to use Fragments. Instead, you can use Views, or ViewGroups. This replaces the nesting of fragments.

11. Detect the level of fragments, that means if you want a fragment 'B' to replace existing fragment 'A', and when you want to go back to show fragment 'A' when pressing back on 'B', put that transaction in back stack.

BETTER APPROACH:
----------------------------------

Each fragment of tab can have child fragments using child fragment manager, with back stack advantage. Thus you can have navigation history for each tab of the ViewPager.

-----------------------------------------------------------

Tip : Carefull while adding swipe feature because there are other clickable views.

Swipe with intercept touch on RootView returning false but analysing touches.

-------------------------

For the Swipe feature handling; properly in your ViewGroups:

 Check which events needs to be intercepted and which are to be passed to the child views:

-------------------------

Swipe gestures on viewgroup

Instead of using my swipe gesture listener in frame-layout on which fragments are attached,
now I am using it on the relative-layouts which are the root-views of the fragments.


    @Override
     public boolean onInterceptTouchEvent(MotionEvent event) {
     boolean intercepted = super.onInterceptTouchEvent(event);
 
     // In general, we don't want to intercept touch events. They should be
     // handled by the child view.
 
     gestureDetector.onTouchEvent(event);
     return false;
     }
 
     @Override
     public boolean onTouchEvent(MotionEvent event) {
     boolean touched = super.onTouchEvent(event);
     gestureDetector.onTouchEvent(event);
     return touched;
     }

Task that remains here is that: intercept the touches in the ViewGroup when the fling is detected, that means return true so that the event is passed to the ViewGroup's onTouch event. This I might achieve by extending the class for the GestureDetector and implement SimpleOnGestureListener.
------------
-----------------------------------------------------------

One more thing: you should observe that having one fragment in one container at a time resolves another issue: If there are two fragments , one on the top of the other, the clicks from one fragment goes to the other fragment that is beneath. So hide or replace to have just one fragment at a time. Back-Stack helps in maintaining the navigation levels, and on configuration change or update, try to update the same instance of the target active fragment, instead of doing transactions because that changes the order of fragments navigated.