This was my first time to hit this group and Mr. Awbrey turned out to be a former president of the organization. It was advertised that there is also an independent Houston Xamarin Users Group that is a meetup.com group as well. Alright, this was refresher on what Xamarin is and it can be a few things. Just as Oracle is sort of an ambiguous term as one could be speaking of the database or one could speaking of the ERP, Xamarin has few products and can mean a few things. The space itself, in a generic sense, has, per the speaker, picked up in interest since Xamarin the company was bought by Microsoft and became a subsidiary of it. James displayed some charts that ostensively showed a spike in interest as of the acquisition and moreover and more importantly he asserted that he now sees companies hiring for Xamarin. I have tried to get into Xamarin before and have goofed off with what Mr. Awbrey would call Traditional Xamarin. As badly as I wanted to get that Xamarin Store app working so that I could get one of those cool free green C# T-shirts, I could not, and when I could not I just gave up as Xamarin did not, at the time, seem to be a real world skill to hone as I never saw it appear in job descriptions when I was chasing work. Is that all about to change? I was getting a soft yes from presenter. As far as my inability to get the Xamarin Store afloat before goes, Jason suggested that he hears all the time of developers complaining of how they couldn't get Xamarin to work in Visual Studio on a PC (which was my circumstance too) and he suggested that while this shouldn't be the case and that it should work, the real way to approach Xamarin development is to get a Macintosh and run Xamarin Studio there. Xamarin Studio was showed off by Jason and it vaguely has a Visual Studio projects-inside-of-solutions feel. Traditional Xamarin apps have solutions with C# base projects and then different UI projects for the iOS and Android breakouts. In order to actually push something for iOS that can get into the Apple Store you have to use some SDKs that Apple provides that cannot run on a PC so you have to, bottom line, develop on a Macintosh. When Jason announced this to the room full of .NET geeks the audience groaned in denial and horror. I've never had to get used to the goofy Macintosh interface (don't need it professionally) or buy a Macintosh laptop. Do I now have to? This is going to be an adjustment. Traditional Xamarin grew out of a beta of MonoTouch and became a third alternative to two bad ways to develop celly apps, the first of these being to have two different code bases for iOS and Android and the later being to make an HTML hybrid app with stuff like PhoneGap, Lua (from the Portuguese word for moon, this is a programming language for "embedded systems" or computers with "dedicated functions" like smartphones which are only so open and not particularly inviting of extension), Cordova, and React Native. The second way, while better than the first, is bad by way of being too consistent. The application will behave the same in both environments and not have the idiomatic feel of a given environment and hence just feel clunky/kludgy to a user used to his phone feeling like his phone and not something foreign. Now, that said, one of the criticisms I have heard of Xamarin in general is that you end up having to write a bunch of platform specific code and are approaching being back in the trap of writing an app for two environments anyways. Jason mentioned just as someone, a C# dev, who knew WinForms in trying to understand web forms could come to the space armed with a lot of the knowledge he needed... he would still be in the situation of having to learn new things, the stateless web, HTTP, etc. ...well also in getting into Xamarin you have to learn to ramp up on a lot of new things like the fact the AppDelegate.cs is the main launching point for an iOS app in their paradigm, etc. One thing that is now making it less painful and addressing the criticism I've heard is Xamarin.Forms (also known as Xamarin 2.0) and in these solutions between the C# layer and the diversified UI layers there is also a common UI layer filled with canned controls for iOS, Android, and I think also Windows Phone environments. These controls behave as they should in each environment, tailored to the space. The thing to assume is that the trend will continue and the future of Xamarin will feature a continuing lessening of the pain of the environment split. Other things mentioned included:
- There is a great community of open source projects to make this space even better. SQLite was suggested to be typically used for the database in these apps and sqlite-crypto was suggested as a way to obfuscate (encrypt) the databases. Also, PCLStorage is a good way to do File I/O stuff. You need a little something extra if you're also targeting Windows Phone as it's sandboxing for "isolated storage" is not the sandboxing for "local storage" of iOS and Android.
- Xamarin Live Player lets you deploy from Windows to one particular iOS device, such as an iPad, for testing, but don't try to squint your eyes and imagine not buying a Macintosh just because of this. That's not the way to go per Jason.
- A .pcl will drive the base C# core underlying project in a solution and by that I do not mean that the base project is the .pcl but that instead it will go into the .pcl for things like the counterparts to System.Web which would come from a .NET .dll in the traditional Visual Studio for-the-web paradigm. A .pcl is not a consistent canned thing like a specific version of a .dll. You make a .pcl by checking some checkboxes for what environments you wish to support and render out a .pcl which will have functionality for C# that may run in the environments selected. Obviously, the more environments you pick, the less the .pcl can do for you.
- Charles Petzold has an eBook on Xamarin.Forms which was recommended.
No comments:
Post a Comment