I'm having a go at creating my first Android app using Xamarin. I'll be needing a database, and the Xamarin docs recommend the "SQLite-net-pcl" NuGet package (here). When I go to install this package it lists approx 50 dependencies that it wants to install! How much is this going to increase the size of my app by?
Is this normal with Xamarin development? Coming from a WPF background I admit I haven't got my head around all this .Net core/standard stuff yet.
And why do the docs recommend this package over the built-in 'Android.Database.Sqlite' namespace? Does the ease of use (of the SQLite.net package) outweigh the increase in app size?
How much is this going to increase the size of my app by?
Not much, Xamarin links out (removes) the unused code when you build your app in release mode. For example if you're not using any methods from System.IO, the assembly will not be included in the final build
Does the ease of use (of the SQLite.net package) outweigh the increase in app size?
Part of it is ease of use and the real advantage is you can reuse the code on iOS or any other platforms. Using Android.Database.Sqlite doesn't help you much if you're planning porting your app to other platforms
What determines which of those 50+ assemblies get pulled into my app?
Dependency on the netstanderd is what pulling those 50+ assemblies, otherwise Sqlite-net-pcl just need SQLitePCLRaw.* assemblies
There is nice series explaining netstanderd from one of the .Net engineers on youtube here - https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY Hope it will answer your questions regarading netstanderd
Related
Failing to extend my existing project with UWP , i search for reason why certain existing projects can't be extended with UWP.
Here i get an answer that all the nuget packages of X.shared project should be the same(with the same version) in the UWP project.
However , even after doing that the project failed to start , so i asked in the
xamarin-docs github and they tell me that the cause is a nuget package supported only in Ios and Android.
So my question is :
Should all the nuget packages be the same for *.ios *.droid, **.\shared and *.uwp ?
And what if i have other projects(not xamarin projects) in my solution ?
You don't understand the architecture of Xamarin and it is hard to answer in one paragraph, further reading of documentation instead of your constant asking of basically the same question on different places (please note that on the github you where warned that it was not the place to ask such a question) is highly advised.
But I'll try to answer. The package may use (or even need to use) native APIs to achieve some functionalities. Those native APIs are available only on one platform and such code is useless on another platform. So the package author in that case must write the separate implementation for each platform that he wants to support. He may cover just one platform or two or three, it is up to the package author. If the platform is not supported by the package and contains the native APIs, there is almost nothing that you can do aside to write your own implementation of the package for that. Even if you succeed in installing it won't work.
I am trying to include Judopay in my project, and I was able to add it to Android and iOS, but not to the Xamarin forms project. There is no NuGet to be included and I can't seem to add the component reference. Any idea on how can I add it? I cannot use any of these:
using JudoDotNetXamarin;
using JudoPayDotNet.Enums;
using JudoPayDotNet.Models;
Again, they only work on iOS or Android, but not Xam forms.
That is because they only provide platform implementations. You will need to tell your Forms app which implementation to use at what time.
The correct way to go about this is with some form of IoC, using dependency injection or service location. Luckily Xamarin Forms has this integrated:
https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/dependency-service/introduction/
Using the references from the Android or iOS projects in your shared code will likely not work completely or break things. Maybe not immediately but surely later on. (Except when there really is no platform-specific functionality, then you might get away with this.)
I have some Android development experience along with React.js. I'm working on a new mobile project and I haven't been sold entirely on either framework yet.
I'm thinking about using the NativeScript framework for its maturity and because it has more libraries with the functionality that I need but I'd like to design my views in a manner similar to ReactJS. I know I could write my own modules for ReactNative but that would require then I'd have to write modules for both Android and iOS. I'd like to avoid that if I could.
I was thinking about importing the necessary ReactNative libraries into a NativeScript project and then being able to write views in a way similar to ReactNative but still using NativeScript.
Is this doable?
Not sure about your exact question. I did just see an integration between Preact and NativeScript you may be interested in. Take a look here: https://github.com/staydecent/nativescript-preact
I believe that repo is in the early stages, but if enough people want something similar, it'll get worked on faster.
Using React Native in NativeScript is not the right approach, either of it are not built to work together and wouldn't work due to architectural reasons. Here is an NativeScript official comparison of these two.
Both are built for solving same problem (building native apps using JS, without webview hybrid app approach) by trans-compiling XML based view layer(which both these framework has its own syntax and so cant be shared) to build Native UI.
Said that view layer has its own syntax for both and cant be shared, model and controller layer cant be shared as well, due to the fact that NativeScript has few things packed as part of the application package, like JavaScript runtime, c++ and Java API layer which helps in exposing all the Native API without the need for any explicit native API wrapper we have in ReactNative.
React Native have platform specific UI components as well as hardware capabilities, which is not the case with NativeScript. Offcouse, that comes with the cost of a fatter app package size(50+MB) compared to <10MB for ReactNative. More on ReactNative vs NativeScript comparison here.
After spending two straight days chasing the answer, I have to fall back and just ask:
Is it possible to perform Sqlite sync via Azure Mobile Services completely within Xamarin Forms iOS PCL project?
Any examples I have looked at (including those that claim that their emphasis is on PCL) all end up instantiating the MobileServicesClient within the Native iOS part of the solution, as well as performing the Sqlite sync via Azure Mobile Services within the native project as well.
My goal is to have a Xamarin.Forms solution, which relies on a Sqlite / Azure Mobile Services sync for all of its data and its offline needs. Such solution would not have to have any additional platform specific code, beside what is generated by the project template.
Furthermore, I intent on using Syncfusion Xamarin charts library, which only works within Xamarin.Forms project. The idea is to have Syncfusion chart source its data from the local Sqlite db, which, in turn, is periodically auto-refreshed using Azure Mobile Services Sqlite sync.
I think, that if I had to do all if the data sync business within my platform specific project, then I may not be able to use this Syncfusion Forms-only library.
Is it actually possible to do the Sqlite / Azure sync completely within the bounds of the PCL?
-Eugene
Yes, you can do so. Check out the book - http://aka.ms/zumobook - particularly Chapter 3. In addition, check out the underlying repo (link in the book) - there are several example setups of Xamarin Forms with Offline Sync in SQLite in there. The Chapter3 sample is a good place to start.
I'm able to use them with my project with removing Silverlight optins from my PCL project because of some System.Web methods are not available with it.
On PCL:
Microsoft.IdentityModel.Clients.ActiveDirectory
Newtonsoft.Json
SQLite.Net
SQLite.Net.Async
On iOS Project:
Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.1.0.0
Microsoft.IdentityModel.Clients.ActiveDirectory.Platform
Newtonsoft.Json
SQLite.Net
SQLite.Net.Platform.XamarinIOS.Unified
I am doing a project for multiple platforms where I have followed best practices and created a core project to contain all the code that is the same on all platforms.
To do the network communication I would like to use HttpClient which seems to be the recommended approach for communicating with web services going forward.
I am NOT doing a PCL but just a standard C# library to contain the core project. However it seems that there is no common implementation of HttpClient but only platform specific ones. I cannot reference and use it in my core but only in my Android and iOS projects.
I would very much prefer to have all networking code in my core project and as I see it there are two options - neither of which I like.
Make a common interface that I can use in the core project that is implemented as a wrapper on both Android and iOS.
Use another technology that is supported in the core project - I am thinking webclient or the like.
What is the recommended approach and why hasn't Xamarin made HttpClient available as a common library?
Hope someone can help,
Thanks
I recommend checking out ModernHttpClient https://github.com/paulcbetts/modernhttpclient
It is a cross-platform networking library for iOS and Android. From the project:
This library brings the latest platform-specific networking libraries
to Xamarin applications via a custom HttpClient handler. Write your
app using System.Net.Http, but drop this library in and it will go
drastically faster.
You should be able to use System.Net.Http in your core library just fine, I've done it recently.
Make sure your core library is a .Net 4.5 project. There is a setting in project options for selecting the .Net version. After checking this, all you should have to do is reference System.Net.Http.dll.
If that doesn't solve your issue, are you on Windows or Mac(Xamarin Studio)?
I'm afraid you can't use HttpClient on Mono at the moment due to licensing restrictions. There is a UserVoice suggestion that you can vote on if you like.