Why to synchronize with remote database?

First question to ask is why to synchronize with a remote database at all?

There are a few obvious advantages:

(+) users’ data is stored “in a cloud” and can be accessed from any device

(+) users don’t need to worry about backing-up their data

(+) data storage logic is moved to the web part of the system and with API exposed it can be easier to port it to other platforms

(+) having web API, a web client can be easily added to the system.

However, there are also some harms:

(-) synchronization of local and remote data (online and offline) must be handled

(-) synchronization uses some network data and battery of a mobile device

(-) web API must be maintained and after each change in it mobile app must be adjusted.

Despite all these aspects I’ve been wondering to implement a web API for few different reasons. First of all this could be a great programming experience, very interesting from architectural point of view. Secondly, I think this is a bit old-fashioned and messy that a user needs to export some database/app files backup to his GDrive in order to not lose his data.

Frankly, I just want to have some fun with ASP.NET Core, implement a web API and make MoneyBack working with it Maybe some Linux deployment after all? Let’s create some nice programming playground here

How to synchronize with web API?

That’s the question I’ve been searching an answer for recently. Long story short, the idea is to have a back-end database management system hosted on a web server and mobile app having its own local “mirror” of the database, bidirectionally synchronizing local data with remote database through web API. Mobile app should work in offline-first mode, which means that all operations must be possible to be done locally and potential (not mandatory) synchronization to happen as soon as it’s possible (user is connected to WiFi, has mobile network access etc.)

There are various possibilities and solutions to handle synchronization of mobile app’s data and remote database storage, from synchronization system built from scratch to Azure cloud hosting.

Custom synchronization mechanism

We could of course implement our own data synchronization mechanism. There are many tutorials available, including for instance this one, which describes all the contents quite nicely and I recommend reading it even if you don’t want to implement sync on your own – it helps understanding all the concepts.

Custom synchronization can be a lot of fun, but… why to reinvent the wheel?

Azure Mobile App Service

Microsoft’s Azure Mobile App Service is recommended almost everywhere – on StackOverflow, in the official Xamarin documentation and on a lot of blogs, but its free plan seems to not be worth using (except of performing some simple tests) while paid plans are more enterprisy. It seems great, but for my playground I neither want to pay nor use free plan which may become unusable after re-implementing the whole back-end.

Realm.io

Finally, out of a sudden, I found it. Realm.io is a totally separate database system built especially for mobile solutions. Its Mobile Database may be used as the db framework for a mobile app (Xamarin is also supported), replacing for instance SQLite. After all, Realm Mobile Platform can be used on a server-side handling mobile/web APIs and data synchronization – documentation says it supports .NET Core 1.1. Let’s hope they add support for 2.0 soon.

What’s more it’s all open-source and provides really nice free plans.

Realm.io looks very promising. I’m just a bit worried it’s almost never recommended on the web – is there something wrong with it? Maybe it’s a new stuff? Where’s a catch? Let me know if you’ve had any experience with it.

SQLite-sync.com

Last but maybe not least, I found SQLite-sync.com. The idea seems to be similar to Realm.io, however this product looks less mature. Not even 100 commits on their GitHub with just few contributors. Looking poor compared to Realm.io’s GitHub with more than 2.5k commits only for its .NET component.

The main (and the only?) benefit of using it would be the possibility to keep SQLite database in Xamarin.Android app. Apart from that, I don’t see any dominance over Realm.io.

Summary

As my research shows there are a lot of existing frameworks that help keeping data synchronized between mobile app and a remote back-end, allowing Xamarin app to work in offline-first approach. Microsoft offers great stuff in Azure, but in my opinion it’s not worth investing money for small playground apps.

For the moment I’m for Realm.io. It seems to provide very extended free plan, there’s a lot of resources on the web, folks talk about it on SO…

So now I’m asking you – do you have any experience with data sync in Xamarin apps? If yes, please share your insights and help me to choose the best approach

I’d be grateful for any suggestions!

After the framework is chosen, I will try to design the whole synchronization system and share it with you here.

The post Xamarin.Android – ASP.NET web api synchronization – research appeared first on CodeJourney.net.

Why to keep and restore Activity’s state?

As I already described in my post about Android Activities, the OS may react to some “constant” state changes by calling lifecycle methods during Activity’s life, which may be overridden by the programmer in order to take some additional actions. However, there are some behaviors in Android apps that may change its configuration, after which the state of the Activity (for instance: arrangement or some UI elements or checkboxes’ selections) may be lost if not handled properly.

To give you a real example: in MoneyBack application there is a main screen with two tabs. I noticed that when the second tab is selected:

and the device is rotated:

first tab becomes selected. User is losing his input (selection of the 2nd tab).

Screen orientation change is one of the reasons why we should care about saving and restoring Activities’ states.

Keeping state changes – OnSaveInstanceState()

Each Activity allows us to override OnSaveInstanceState(Bundle outState) method, which is called when the current Activity is to be killed (e.g. when device’s screen orientation is changing or the Activity needs to be killed by Android in order to release some resources).

Please don’t confuse it with Activity Lifecycle Methods (which I already described here), like OnPause() or OnStop() which are always called by the OS when particular action occurs. OnSaveInstanceState() method is generally called after OnPause() and before OnStop(), but it’s not always the case. For instance, it won’t be called at all when user navigates back from ActivityB to ActivityA, as in this case ActivityB will never be killed. More details can be found in official Android documentation.

OnSaveInstanceState() is called with Bundle parameter provided. It represents a simple key-value dictionary, which is additionally serialized, so it should be used for storing simple values like strings, integers etc. There are other structures and techniques for storing more complex data on state changes events (see the link in “Summary” section of this post).

In order to save currently selected tab, we can implement the method as follows:

Now, each screen orientation change will make this method called and the index of selected tab will be saved into Bundle outState dictionary under “selectedTabPosition” key.

Restoring state changes – OnRestoreInstanceState()

As soon as the Activity considered backs to life (is being resumed), OnRestoreInstanceState(Bundle savedInstanceState) method is called by the OS. It will only be called if there is a saved instance kept by calling OnSaveInstanceState() method before. As you can see, this method also comes with a Bundle parameter, which is the same key-value serialized dictionary we used for saving the Activity’s state.

In case of tabs selection restoring, we can implement this method as the following code presents:

previouslySelectedTabPosition variable will be initialized with integer value from Bundle dictionary saved under “selectedTabPosition” key, or default value (0) if nothing saved for the key is found.

NOTE: Bundle parameter provided in OnRestoreInstanceState() is exactly the same, as the one available in OnCreate(Bundle bundle) method called on Activity’s creation. We could actually also retrieve our saved value there, but in many cases restoring the state (like selecting previously selected tab) requires some UI elements to be already initialized, which should be handled within OnCreate() method before. Because of that, I’d rather suggest to restore Activity’s state using OnRestoreInstanceState() as a general rule (of course there may be some exceptional cases ). OnRestoreInstanceState() will always be called after OnCreate().

Moreover, if we wanted to use Bundle parameter in OnCreate() method, we’d need to check each time if bundle is not NULL (as we don’t know whether OnSaveInstanceState() had been called before).

As a result, the same tab as previously is selected even after rotating the device on MoneyBack‘s MainActivity:

“Automatic” state changes handled by Android OS

Maybe you noticed in your Android application, that not every UI element needs to be handled “manually” by implementing the above-mentioned methods in order to save its state. Android performs some kind of “automatic” saving and restoration of basic UI elements’ states.

The rule here is that as long as UI element (like TextView or Button) has its android:id set in .axml layout file, OS will automatically manage those elements’ states (e.g. text entered into EditText).

For example, for EditText declared like that:

its properties (especially its Text property) will be automatically saved and restored on screen orientation changes.

Summary

We’ve seen how to handle Android Activities’ state changes caused by configuration modification (e.g. screen orientation change, Activity being killed by the OS in order to free some resources etc.) by implementing OnSaveInstanceState() and OnRestoreInstanceState(), where we added and retrieved key-value data to/from Bundle serialized dictionary. We just need to remember that those methods are not always called (e.g. when navigating between Activities using “back” button), so these should be used only for certain kind of state changes.

We’ve also seen that UI controls with their android:id defined in layout files have their states resistant for configuration changes (handled automatically by Android OS).

Bundle dictionary is serialized for better performance and memory utilization, so only simple-typed values should be stored in it (like strings or integers). In order to store more complex data, Android provides different possibilities of managing it (e.g. using OnRetainNonConfigurationInstance).

The post Managing Activity state changes using Bundle appeared first on CodeJourney.net.

The dialog looks as follows:

It may be opened e.g. when clicking on a button in the app, as I used it in MoneyBack.

Creating DatePickerFragment

First of all, we will implement the dialog to be displayed within DialogFragment. Doing that our dialog will be able to be displayed as independent piece of UI on the top of any Activity.

The second requirement is to implement IOnDateSetListener interface (coming from Java/Android), which provides a callback on date selection action done by the user.

The DatePickerFragment meeting those two requirements may look as follows:

There are few crucial parts in above-listed class:

• Line 1: as said before, the class derives from DialogFragment and implements IOnDateSetListener interface
• Line 3: here we have public static readonly string TAG variable defined – it is used as a unique identifier of the Fragment; in some cases, Fragments can be displayed without any UI – in such case the only possibility to identify and get the Fragment is by using findFragmentByTag() method
• Lines 5-10: define _dateSelectedHandler delegate which may be provided to the constructor of our DatePickerFragment with the method to be called-back when user selects a date
• Lines 12-20: inheriting from DialogFragment allows us to override its lifecycle methods – one of them is Dialog OnCreateDialog(Bundle savedInstanceState), in which we actually create the Dialog-inheriting class – in our case – DatePickerDialog – with initially selected date (set to current date in the provided example)
• Lines 22-26: implementing IOnDateSetListener interface requires to implement OnDateSet method, which is called when the user selects the date and clicks “OK” button;
  NOTE: one of this method’s arguments is monthOfYear integer value, which contains month number expressed as values 0-11 (NOT 1-12) for compatibility with java.util.Calendar.MONTH

Using DatePickerFragment

In MoneyBack application I’ve used DatePickerFragment on creating/modifying an event, when user needs to select its date:

As soon as the button is clicked, the following code executes:

As you can see, to DatePickerFragment‘s constructor I’m providing the delegate with a method to be called when the date is selected by the user (setting _selectedDate property with selected time and putting the date in short format as button’s Text).

In order to display a dialog, Show method is called, taking current FragmentManager and already mentioned per-Fragment-unique tag string, defined statically in DatePickerFragment class.

Summary

Today’s short post presented how to easily create a DialogFragment showing DatePickerDialog for date selection, which allows to provide any method to be called-back when the date is selected by the user.

I hope you’ll find it useful

The post Date selection using DatePickerDialog in Xamarin.Android appeared first on CodeJourney.net.

In general, the project hasn’t been going as well as I expected and is currently not as advanced as I’d expect it to be at this stage. There are many reasons behind that, including lack of time recently and many issues met during development, however, as I already wrote in my DSP introducing post, the most important is to survive with the project to the end of the competition and meet all requirements. The end of DSP doesn’t equal the end of MoneyBack

That’s why in this post I’d like to show you how the project looks currently and what’s still to be done. Moreover, as I promised before, I’m publishing my Trello board with tasks still to be done within the project.

UI changes

For the last days working on the project I’ve been trying to make the UI of MoneyBack some kind of “final” version, so I can easily extend it adding new functionalities and focus on development instead of spending time on interface design, which is not important for me at the moment. I met many issues with that, which I think came from using some deprecated UI elements I used (e.g. ListView and Adapters) that are not fully-supported in the newest versions of Android. Tutorials are also not really up-to-date for those components. Maybe that’s also because when I wanted to implement displaying a list of entities I looked in Google for something like “xamarin android list of elements” which lead me to this ListView and Adapters tutorial. Instead of firstly reading the whole User Interface tutorial, I wanted to implement displaying the list quickly, so I used those deprecated elements instead of implementing for instance newer and recommended RecyclerView from the beginning, which would be easier extensible now. That definitely teaches me that I should get to know a particular topic/area better and wider before deciding to use one of the possible solutions to solve a problem. Sometimes we want to implement something particular quickly, but later it produces more issues than benefits.

Finally I added tabs (only one tab for People for now, but it will be easy to add new ones now) and ActionBar menu on the main Activity of the app:

On the screenshot above, in the right-upper corner there is “Add” button visible when clicking on ActionBar menu. It opens a new person’s adding screen, on which I made name and email fields mandatory:

People added are then displayed on the main screen of the app in “People” tab:

Code – interesting parts

Using tabs layout in an Activity

It turned out that using tabs-like layout in the Activity is pretty easy. In the AXML layout file for MainActivity I just added a FrameLayout container, within which the tabs and their contents are to be displayed:

I called it tabFragmentsContainer, because within each tab we will display a Fragment. Fragment represents a part of UI and/or behavior, which is displayed within an Activity. You can think of Fragments as smaller pieces, that can be placed onto (inside) Activities.

Basically, I changed PeopleListActivity to PeopleListFragment, which in fact only required changing inheritance from being a child of Activity to inheriting from ListFragment (which is a special kind of Fragment used for displaying lists of elements). The complete code of PeopleListFragment can be found in this public Gist.

In the end, making MainActivity displaying tabs requires setting its ActionBar’s navigation mode to ActionBarNavigationMode.Tabs:

this.ActionBar.NavigationMode = ActionBarNavigationMode.Tabs;
and adding as many tabs as you wish, using for instance code similar to the following one:








  





void AddTab(string tabText, Fragment view)



{



    var tab = this.ActionBar.NewTab();



    tab.SetText(tabText);








    tab.TabSelected += delegate (object sender, ActionBar.TabEventArgs e)



    {



        var fragment = this.FragmentManager.FindFragmentById(Resource.Id.tabFragmentsContainer);



        if (fragment != null)



            e.FragmentTransaction.Remove(fragment);



        e.FragmentTransaction.Add(Resource.Id.tabFragmentsContainer, view);



    };



    tab.TabUnselected += delegate (object sender, ActionBar.TabEventArgs e) {



        e.FragmentTransaction.Remove(view);



    };








    this.ActionBar.AddTab(tab);



}






        view raw

        

          MainActivity_AddTab.cs

        

        hosted with ❤ by GitHub
      


The arguments are name of the tab and an instance of a Fragment we want to have displayed in this tab (PeopleListFragment‘s instance in our case).
Lines 6-12 present what happens when the tab is selected by the user – Fragment‘s instance is added to previously defined tabFragmentsContainer.
Lines 13-15 define callback method on tab deselection – Fragment is removed from the container.
Adding ActionBar with menu to the Activity
Addition of ActionBar with menu button in right-upper corner of the Activity requires creating an XML view in Resources/menu folder first (with one button in our case):








  





<menu xmlns:android="http://schemas.android.com/apk/res/android">



  <item android:id="@+id/menuAdd"



        android:title="@string/menuAddTitle"/>



</menu>






        view raw

        

          ActionBarMenu.xml

        

        hosted with ❤ by GitHub
      


and then in the Activity considered overriding OnCreateOptionsMenu method inflating ActionBar’s menu using created view:








  





public override bool OnCreateOptionsMenu(IMenu menu)



{



    MenuInflater.Inflate(Resource.Menu.ActionBarMenu, menu);



    return base.OnPrepareOptionsMenu(menu);



}






        view raw

        

          MainActivity_OnCreateOptionsMenu.cs

        

        hosted with ❤ by GitHub
      


We also need to define what happens when a menu option is selected. For that purpose, override OnOptionsItemSelected method:








  





public override bool OnOptionsItemSelected(IMenuItem item)



{



    if (item.ItemId == Resource.Id.menuAdd)



    {



        OpenAddingNewPerson();



        return true;



    }








    return base.OnOptionsItemSelected(item);



}






        view raw

        

          MainActivity_OnOptionsItemSelected.cs

        

        hosted with ❤ by GitHub
      


Next coding tasks
From now on you can watch my public Trello board, where I have all tasks to be done in the nearest future in MoneyBack defined. I will try to define deadlines for those tasks as well.
At the moment of writing this post, I’ve started adding a possibility to create Events. I will need to keep many-to-many relationship between Person and Event entities and I will probably use SQLite-Net Extensions library for that. You can expect a separate post about defining relationships using this library soon 
Other tasks left to be done
Apart from coding and developing the project, I still need to fulfill the DSP competition’s requirements. This is my 14th post within DajSiePoznac2017, so 6 posts still to be written. I have the ideas in my mind already and few next posts planned. There are only 3 weeks left to the end of the competition, so those days will need to be more intensive that it recently was, but that’s good, it means that you should be receiving more content here in the coming days and I will be spending more time on developing MoneyBack. Only positive changes, I hope 
Summary
We saw the status of MoneyBack project today. There are still many things to be done in the app to at least fulfill the minimal requirements I assumed in the beginning of the competition. but as I mentioned, the end of DSP is not the end of MoneyBack  On the other hand, DSP is a very good motivator, so I’ll try to make coming days and weeks more intensive. The most important goal for now is to fulfill the competition’s requirements for having 20 posts written until the end of May, which shouldn’t be problematic at all 
I’ve also published my Trello dashboard. You can find a link to it here.
Using this opportunity, I’d like to wish all DSP’17 participants good luck in the last weeks of the competition. I’m constantly reading the others’ blogs and I see a lot of very nice and decent quality stuff appearing in Polish programming community on your blogs and repositories – great job!
Keep your fingers crossed! 
The post MoneyBack – 3 weeks before the end of DSP appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/moneyback-3-weeks-before-the-end-of-dsp/feed/
			0
		
		
		2192