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.

Using ADB to debug Android apps

By default, adb is configured to “map” Android devices connected via USB ports to the computer as debug devices, which are then available e.g. in Visual Studio as the device on which our app can be deployed and debugged. In may cases we debug apps on Android emulators, which is frequently fair enough, but at some point we need to make our tests on a physical device.

It may not be very comfortable to have the phone connected using USB cable all the time, especially when testing some physical sensors like accelerometer or gyroscope. For such purposes, ADB gives us the possibility to connect Android devices via WiFi instead of USB. Let’s see how to configure it.

Configure ADB to work on WiFi

The first requirement is – obviously – that both our development PC and Android device must be connected to the same WiFi network. Then we need to find out what is the IP address of our Android device – it can be checked by going to Settings -> WiFi -> Menu – Advanced settings (Android 6.0):

As soon as you have IP address of the device noted, connect it to the computer via USB port.

Now we need to use adb.exe to configure it for connecting with the device via WiFi. You can either add system environmental variable pointing to where the adb.exe is stored or just open cmd, go to the catalogue where it’s located (Android\platform-tools\) and execute the following commands:

1. Change ADB to listen on TCP port:

adb tcpip 5555
This will make ADB listening on TCP port 5555 instead of USB ports (NOTE: since now the computer won’t listen to any devices connected by USB ports):

Now, disconnect the Android device from USB port.
2. Make ADB connect to your Android device:
adb connect 192.168.0.101:5555
This command is used to connect to Android device (of course IP address must be changed with your device’s one) on port 5555 using WiFi:


3. Since now you should see the device in Visual Studio connected using WiFi connection:

and you can of course deploy the app remotely on the device and debug it 
4. As soon as you’re done with WiFi debugging, run the following command:
adb usb
It will make ADB listening for USB devices again:

TIP: if during performing any cmd commands adb.exe is stuck or not reacting, try plugging out and re-plugging in your Android device to USB port.
Summary
This post described how to use remote debugging on Android devices using WiFi connection.
I hope you’ll find it useful 
The post Xamarin.Android – debugging via WiFi appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/xamarin-android-debugging-via-wifi/feed/
			4
		
		
		2296	
		
		
		https://www.codejourney.net/managing-activity-state-changes-using-bundle/
					https://www.codejourney.net/managing-activity-state-changes-using-bundle/#respond
		
		
		Mon, 29 May 2017 21:28:42 +0000
				
		
		
		
		
		
		
		http://www.dsibinski.pl/?p=2281

					Today we’re going to see how to manage (keep and restore) state of Activities in Xamarin.Android application in order to keep the app consistent and reactive for configuration/state changes. 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…

The post Managing Activity state changes using Bundle appeared first on CodeJourney.net.
]]>
										Today we’re going to see how to manage (keep and restore) state of Activities in Xamarin.Android application in order to keep the app consistent and reactive for configuration/state changes.


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:








  





  protected override void OnSaveInstanceState(Bundle outState)



  {



      var tabSelectedPosition = this.ActionBar.SelectedNavigationIndex;



      outState.PutInt("selectedTabPosition", tabSelectedPosition);








      base.OnSaveInstanceState(outState);



  }






        view raw

        

          OnSaveInstanceState.cs

        

        hosted with ❤ by GitHub
      


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:








  





  protected override void OnRestoreInstanceState(Bundle savedInstanceState)



  {



      base.OnRestoreInstanceState(savedInstanceState);








      var previouslySelectedTabPosition = savedInstanceState.GetInt("selectedTabPosition", 0);



      this.ActionBar.SetSelectedNavigationItem(previouslySelectedTabPosition);



  }






        view raw

        

          OnRestoreInstanceState.cs

        

        hosted with ❤ by GitHub
      


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:








  





  <EditText



  android:layout_width="match_parent"



  android:layout_height="wrap_content"



  android:id="@+id/inputEventName"



  android:fadingEdge="none" />






        view raw

        

          EditText.axml

        

        hosted with ❤ by GitHub
      


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.
]]>
					
					https://www.codejourney.net/managing-activity-state-changes-using-bundle/feed/
			0
		
		
		2281	
		
		
		https://www.codejourney.net/date-selection-using-datepickerdialog-in-xamarin-android/
					https://www.codejourney.net/date-selection-using-datepickerdialog-in-xamarin-android/#respond
		
		
		Sat, 27 May 2017 13:19:47 +0000
				
		
		
		
		
		
		
		http://www.dsibinski.pl/?p=2266

					In this post, we’re going to see how to provide a nice Android UI control for selecting the date using DatePickerDialog. 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…

The post Date selection using DatePickerDialog in Xamarin.Android appeared first on CodeJourney.net.
]]>
										In this post, we’re going to see how to provide a nice Android UI control for selecting the date using DatePickerDialog.


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:








  





  public class DatePickerFragment : DialogFragment, DatePickerDialog.IOnDateSetListener



  {



      public static readonly string TAG = "X:" + typeof(DatePickerFragment).Name.ToUpper();








      Action<DateTime> _dateSelectedHandler = delegate { };








      public DatePickerFragment(Action<DateTime> onDateSelected)



      {



          _dateSelectedHandler = onDateSelected;



      }








      public override Dialog OnCreateDialog(Bundle savedInstanceState)



      {



          DateTime now = DateTime.Now;



          return new DatePickerDialog(Activity, 



              this,



              now.Year,



              now.Month,



              now.Day);



      }








      public void OnDateSet(DatePicker view, int year, int monthOfYear, int dayOfMonth)



      {



          DateTime selectedDate = new DateTime(year, monthOfYear + 1, dayOfMonth);



          _dateSelectedHandler(selectedDate);



      }



  }






        view raw

        

          DatePickerFragment.cs

        

        hosted with ❤ by GitHub
      


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:








  





  private void _btnSelectDate_Click(object sender, EventArgs e)



  {



      new DatePickerFragment(delegate(DateTime time)



          {



              _selectedDate = time;



              _btnSelectDate.Text = _selectedDate.ToLongDateString();



          })



          .Show(FragmentManager, DatePickerFragment.TAG);



  }






        view raw

        

          EventDetailsActivity_DateClick.cs

        

        hosted with ❤ by GitHub
      


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.
]]>
					
					https://www.codejourney.net/date-selection-using-datepickerdialog-in-xamarin-android/feed/
			0
		
		
		2266	
		
		
		https://www.codejourney.net/sqlite-net-extensions-one-to-many-relationships/
					https://www.codejourney.net/sqlite-net-extensions-one-to-many-relationships/#comments
		
		
		Mon, 22 May 2017 22:01:46 +0000
				
		
		
		
		
		
		
		http://www.dsibinski.pl/?p=2251

					In the 3rd post from SQLite-Net Extensions series we are covering the last type of relationship – one-to-many (and the opposite – many-to-one). One-to-many, many-to-one One-to-many relationships are used in general for parent-children or whole-elements relations. Classic examples are: bus and passengers, document and elements etc. One-to-many relationship means that the one-end entity knows about its…

The post SQLite-Net Extensions – one-to-many relationships appeared first on CodeJourney.net.
]]>
										In the 3rd post from SQLite-Net Extensions series we are covering the last type of relationship – one-to-many (and the opposite – many-to-one).


One-to-many, many-to-one
One-to-many relationships are used in general for parent-children or whole-elements relations. Classic examples are: bus and passengers, document and elements etc.
One-to-many relationship means that the one-end entity knows about its children and many-end entity has a reference (foreign key) to its parent (but not necessarily knows about it).
On the other hand, the opposite relationship to one-to-many is many-to-one. In that case, many-end entity has a reference to its parent and knows about it, but the one-end entity doesn’t necessarily know about its children (at least not directly).
I used a verb to know several times – so it’s time to explain it 🙂 By “knowing” about the other end of a relationship I understand having a reference to it. It means that, for instance, in many-to-one relationship, the one-end of it doesn’t have a reference to its children.
However in most cases what we’d like to have is a hybrid of one-to-many and many-to-one relationships. I will call it one-to-many with inversion. We want both parent to know about its children, and each children to know about its parent.
In this post we’ll cover one-to-many with no reversion and one-to-many with reversion, as it also includes many-to-one relationship so you can have a comprehensive overview. We are going to see it on the example of Employee and Duty* entities. Each employee has a list of his duties, whilst each single duty is assigned to only one employee.
* “Task” would probably be a better name, but I didn’t want to make it confused with .NET Tasks 🙂
One-to-many with no inversion
Firstly, let’s model this kind of relationship:

Now we can transform it into C# classes:








  





    [Table("Employees")]



    public class Employee



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Name { get; set; }



        public string LastName { get; set; }








        [OneToMany]



        public List<Duty> Duties { get; set; }



    }






        view raw

        

          Employee.cs

        

        hosted with ❤ by GitHub
      


In the Employee class (parent, one-end of the relationship) we define the collection of children, decorated with OneToManyAttribute. Collections types supported as for the time of writing this post by SQLite-Net Extensions are List and Array and can be used as you prefer.
Let’s now see how the child entity (Duty) looks like:








  





    [Table("Duties")]



    public class Duty



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Description { get; set; }








        public DateTime Deadline { get; set; }








        [ForeignKey(typeof(Employee))]



        public int EmployeeId { get; set; }



    }






        view raw

        

          Duty.cs

        

        hosted with ❤ by GitHub
      


In the Duty class (child, many-end of the relationship) we need to have a foreign key to parent entity defined. For that purpose, we create a property representing it (EmployeeId), decorating it with ForeignKeyAttribute, additionally specifying the type of parent referenced (Employee).
That’s it. We can already use it in our code:








  





  var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



  db.CreateTable<Employee>();



  db.CreateTable<Duty>();








  var employee = new Employee



  {



      Name = "Andrew",



      LastName = "Programmer"



  };








  var duty1 = new Duty()



  {



      Description = "Project A Management",



      Deadline = new DateTime(2017, 10, 31)



  };








  var duty2 = new Duty()



  {



      Description = "Reporting work time",



      Deadline = new DateTime(2022, 12, 31)



  };








  db.Insert(employee);



  db.Insert(duty1);



  db.Insert(duty2);








  employee.Duties = new List<Duty> {duty1, duty2};



  db.UpdateWithChildren(employee);








  var employeeStored = db.GetWithChildren<Employee>(employee.Id);






        view raw

        

          EmployeeDuty_noInv.cs

        

        hosted with ❤ by GitHub
      


No rocket-science here. What’s interesting for us it how employeeStored looks in the end:

As you can see, GetWithChildren method returned object of type Employee with its Duties collection properly retrieved (containing two duties assigned to the employee before). Moreover, each children has its foreign key (EmployeeId) automatically retrieved from the DB – there is no overhead here, this is simply foreign key field stored in the same SQLite database table (Duties).
One-to-many with inversion (one-to-many + many-to-one)
As previously, let’s first see how the class diagram changes after adding inversion:

What changed is that now each Duty has a property of type Employee.
To realize the above class diagram and make each children (each Duty in our case) knowing about its parent (having a reference to responsible Employee), the only thing we need to do is to add the following property to Duty model class:
[ManyToOne]
public Employee Employee { get; set; }
so the model class finally looks as follows:








  





  [Table("Duties")]



  public class Duty



  {



      [PrimaryKey, AutoIncrement]



      public int Id { get; set; }








      public string Description { get; set; }








      public DateTime Deadline { get; set; }








      [ForeignKey(typeof(Employee))]



      public int EmployeeId { get; set; }








      [ManyToOne]



      public Employee Employee { get; set; }



  }






        view raw

        

          Employee_withInv.cs

        

        hosted with ❤ by GitHub
      


As you can see, we have just created many-to-one relationship by using ManyToOneAttribute. So currently we have the hybrid of both types of relationships within out two models.
The usage in our code doesn’t need to be changed at all. Now, employeeStored entity after being initialized by the same GetWithChildren method as previously, for each Duty in addition to EmployeeId field also contains Employee property properly retrieved by SQLite-Net Extensions:

Again, there is no db overhead here, because when retrieving Employee entity from the database we already have it, so the operation of initializing the Employee entity in each Duty contained within Duties collection doesn’t require any more database querying.
Summary
Today we’ve seen how to model and use one-to-many (with and without inversion) relationships in SQLite database with the usage of SQLite-Net Extensions. The automatic initialization of one-end or many-end entities by the ORM is extremely helpful when dealing with such kind of objects in our app. The amount of code to be written is also minimal.
We’ve covered one-to-many and a hybrid of one-to-many + many-to-one relationships, but of course you can also define just many-to-one relationship – the models would then look as in this Gist. For me, it makes very limited sense, but maybe can be useful in some specific situations.
I invite you to read my other posts about SQLite-Net Extensions ORM, where we also covered the other types of relationships that can be modeled using this library.
As this is already the third post from this series, I’d like to ask you: what do you think about SQLite-Net Extensions ORM? Do you find it useful? Do you use it in your apps? Can you can recommend some other libraries/ORMs to use with SQLite database that allow to model different kind of relationships?
The post SQLite-Net Extensions – one-to-many relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-many-relationships/feed/
			2
		
		
		2251	
		
		
		https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/#comments
		
		
		Sun, 21 May 2017 10:18:15 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2238

					In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM. One-To-One This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated…

The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
										In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM.


One-To-One
This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated with one and only one vehicle (excluding some extraordinary law rules in other countries that I don’t know  ).
We can model it in two ways:

as a one-way relationship – in this case only one of the relationship’s ends knows about the other one
as a both-ways (with inversion) relationship – both relationship’s ends know about each other.

One-To-One with no inversion (one-way)
This kind of relationship looks as follows:

We use it when we assume it’s enough that Vehicle knows about RegistrationCertificate, but the document doesn’t necessarily need to know which car/motor it’s associated with (at least directly).
In the code, we then create two model classes using SQLite-Net Extensions:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }



    }






        view raw

        

          RegistrationCertificate.cs

        

        hosted with ❤ by GitHub
      










  





    [Table("Vehicles")]



    public class Vehicle



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Brand { get; set; }








        public DateTime ProductionDate { get; set; }








        public decimal EngineCapacity { get; set; }








        [ForeignKey(typeof(RegistrationCertificate))]



        public int RegistrationCertificateId { get; set; }








        [OneToOne]



        public RegistrationCertificate RegistrationCertificate { get; set; }



    }






        view raw

        

          Vehicle.cs

        

        hosted with ❤ by GitHub
      


What’s interesting here is the ForeignKeyAttribute defined on RegistrationCertificateId property. It is – as its name says – the foreign key to the primary key of related entity (of type RegistrationCertificate).
The related entity property itself is decorated with OneToOneAttribute.
There’s nothing more we need to do to have this relationship modeled. We can already use it:








  





    var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



    db.CreateTable<Vehicle>();



    db.CreateTable<RegistrationCertificate>();








    var vehicle = new Vehicle



    {



        Brand = "Renault",



        EngineCapacity = 1.9m,



        ProductionDate = new DateTime(2001, 01, 01)



    };








    var certificate = new RegistrationCertificate



    {



        RegistrationNumber = "AB 12345",



        OwnerData = "Dawid Sibiński",



        VIN = "1312BS1312ASDSSVVW"



    };








    db.Insert(vehicle);



    db.Insert(certificate);








    vehicle.RegistrationCertificate = certificate;



    db.UpdateWithChildren(vehicle);








    var vehicleStored = db.GetWithChildren<Vehicle>(vehicle.Id);






        view raw

        

          OneToOne_noInv.cs

        

        hosted with ❤ by GitHub
      


Nothing special here, right? It looks very similar to what we’ve seen in the previous post about many-to-many relationships. What’s interesting for us it that in the end, when Vehicle object is retrieved from the database using GetWithChildren method, its RegistrationCertificate property is filled as well:

One-To-One with inversion (both-ways)
This kind of relationship models itself as below:

What actually changed on the diagram compared to the relationship with no inversion is that now RegistrationCertificate has a property of type Vehicle (in the code – a reference to Vehicle related object and a foreign key).
In our case, this is even more “real” – it would be nice if a Vehicle knows about its RegistrationCertificate, but also when we look at the certificate we’d like to see to which car it belongs.
We can now model it in the code. The only thing that changes in the model classes is addition of a reference and foreign key to Vehicle in RegistrationCertificate model, so I’m presenting only this class’s updated code:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }








        // added to have Inversion relationship



        [ForeignKey(typeof(Vehicle))]



        public int VehicleId { get; set; }








        [OneToOne]



        public Vehicle Vehicle { get; set; }



    }






        view raw

        

          RegistrationCertificate_withInv.cs

        

        hosted with ❤ by GitHub
      


What’s cool here is that we don’t need to modify our code for saving entities with relationships into SQLite database. We can simply add the following line at the end:
var certificateStored = db.GetWithChildren&lt;RegistrationCertificate&gt;(certificate.Id);
and notice that certificateStored already contains its associated Vehicle object:

Summary
In today’s short post we’ve seen how to create one-to-one relationship between two entities in SQLite database, using SQLite-Net Extensions ORM. It’s very easy and doesn’t require using Entity Framework  or writing SQL queries directly in our code.
We’ve covered two types of one-to-one relationships: one-way and both-ways. The choice between those two depends on the usage and purpose of the relationship we model.
I hope you’ll find it useful one day 
The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/feed/
			2
		
		
		2238	
		
		
		https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/
					https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/#comments
		
		
		Thu, 18 May 2017 21:23:31 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2218