Jim Wilson (a.k.a. hedgehogjim)
30+ years as a professional software dev, 17+ years developing mobile solutions, Pluralsight Author, Founder JWHH, LLC
Packt is celebrating the release of their 2,000th title and has a special offer!
Packt is throwing in a free eBook of your choice with the purchase of my book, Creating Dynamic UI with Android Fragments.
Actually they’re doing that for all of their eBook titles but I thought I’d take this chance to plug mine. 🙂
Whatever titles you choose, it’s a great deal!!
I’ve been working with Xamarin a great deal the past several months and am increasingly becoming a fan of the product. The ability to leverage the Visual Studio IDE, familiar .NET class libraries, and C#programming language to create both Android and iOS apps provides incredible power.
The beauty of working with Xamarin is that it allows us to share code when doing so makes sense but Xamarin also embraces the unique features of each platform. Xamarin does this by going beyond the many .NET classes that we’re all familiar with to also include .NET classes that expose the features of each platform.
As an example, the features of Android activities are available through a .NET Android.App.Activity class. Similarly, there’s a .NET MonoTouch.UIKit.UITableViewController class that makes the iOS UITableViewController features available. The platform-specific features provided by Xamarin are extremely rich and comprehensive giving us access to most any platform features we’re likely to use.
By having both the standard .NET classes and platform-specific .NET classes we’re able to build our application’s core logic just once, sharing that logic across both platforms, while also having full access to each platform’s unique capabilities and features.
If you’d like to learn more about working with Xamarin, I encourage you to checkout my 2 part course series on cross-platform app development with iOS and Android. Pluralsight just published part 2 of the series this week.
BTW: Although the 2-part series on cross-platform iOS/Android development with .NET/C# is complete there’s still a lot more to content to come. Keep watching for more courses on using Xamarin to create Android and iOS apps.
Although Fragments have been part of the Android API for nearly three years, I find that developers still often struggle to understand their value and purpose.
A common explanation of Fragments, and one I sometimes even use myself, is:
Fragments group user interface components and their associated logic.
That explanation is accurate. However, if someone is struggling with how to apply Fragments in a practical sense, that explanation is about as useful as teaching someone how to tell time by explaining the finer details of Swiss watch construction … sometimes you just want to know what time it is…
I’m often asked by students from my Android courses as to how I’m able to use Lambda expressions like the following in my Android programs.
The short answer is: I’m not able to use them. 🙂 What I typed was the following.
The Lambda expressions appear in the editor due to a feature of Android Studio called “Code Folding”.
Android Studio does this sort’a thing in a number of scenarios. You can tell the Lambda expression is a result of code-folding by the highlight that appears over the folded portion of code.
You can also easily identify that the Lambda expression is a result of code folding because the editor will display a plus-sign to the left of the statement. You can view the full, original statement by clicking on the plus sign.
Lamba expression substitution is controlled by the following value in the Android Studio Settings dialog.
As this is my first post of 2014, let me take this opportunity to wish everyone … Happy New Year!!
I’m happy to report that since my previous post, I am now able to build the iOS app without any difficulty. Thanks again to James Montemagno at Xamarin for his help.
BTW: My apologies for the 4-day gap between posting on the issue. I was out of town and didn’t have my Mac with me so couldn’t do the iOS part of the build.
The reason I encountered errors & warnings when building the iOS project is due to the fact that when the wizard generates the project it does not fill in 3 key fields in the project properties: Application Name, Identifier, and Version. The fields are all blank as shown here.
I filled those in with the appropriate values as shown here…
… and all builds well.
One bit of frustration is that I didn’t see anywhere in the Xamarin Hello, iPhone documentation where it said I had to fill these values in for a valid build.
Near the end of the documentation it does mention that one can edit the plist file using property pages. However, the screen shot shows the Identifier and Version fields empty giving one the impression that leaving them blank is OK.
With those values being so important, I would’ve preferred that Xamarin did one of the following (listed in my order of preference).
In fairness, the error/warning messages do indicate that the values need to be set on the property page. It’s just that after the other headaches I was experiencing, seeing an untouched, wizard-generated project fail to build left me a bit discouraged.
IMHO – When working with a brand new environment, its critical that what comes out of the wizard must build without any errors. So often all one is trying to do is verify that the pieces are working and build errors on untouched wizard-generated projects give one the impression that something is wrong. 🙂
One little thing that surprised me is that Visual Studio is not updating the status bar to indicate that a successful build has completed. In the case of a standard Visual Studio project, the status bar displays a message like the following indicating build success.
In the case of my VS solution containing the iPhone project, the status bar does not update with a success message as you can see here.
I’ve had to have the Output window open so that I can see when a successful build completes.
Although I haven’t tried to exhaustively diagnose the cause, the lack of a success message appears to be tied to the fact that the solution contains an iPhone project (Xamarin will often display the Mac build host IP Address in the status bar). When I create a solution containing only an Android project, the build result displays in the status bar as expected.
Just to follow up on the issue I mentioned in my last post about the Xamarin.Android Beta breaking Xamarin.iOS in Visual Studio.
The folks at Xamarin have followed up and let me know that there is an incompatibility between the Xamarin.Android version that is currently in Beta and the production release of Xamarin.iOS. To safely install the Xamarin.Android Beta, I’ll need to install the corresponding Xamarin.iOS Beta … A very reasonable requirement.
You can find the bug report and Xamarin’s response here.
I’m not sure if I’m going to do the Beta installs right now or not. I may just wait for them to reach production release. I’ll keep y’all updated if I do decide to install the Betas.
So everything appears to now be working. I can start really digging into things now.
I do want to give Kudos to the folks at Xamarin…
So far every issue I’ve raised whether in their Forums or on their Bugzilla page has been responded to in a very reasonable time frame. Thanks guys!
I’ve been wanting to dig into using Xamarin to do iOS/Android development in Visual Studio/C# for a while now. So finally had a chance to start looking into it closely.
Update: After you read this post, checkout the follow up.
I now have everything setup and running. I must admit that creating my first Android and iOS projects was not as a satisfying has I had hoped. There’s a bit of flaky behavior in the Android UI designer and the wizard generated projects for both Android and iOS have problems.
Let’s look at the Android side of things first.
The initial problems I ran into were tied to unexpected UI designer behavior I encountered when it was first opened.
The first two issues are easily resolved by simply taking some action that causes the design window to resize: explicitly resizing it, hiding/showing the toolbox, etc.
It turns out that the design-view/XML-view toggle buttons are not supported for VS2013 in the current stable release of Xamarin.Android (4.10.1), although they are supported in earlier VS versions and in Xamarin Studio (Xamarin’s stand-alone IDE). I checked around and found that the beta version of Xamarin.Android 4.10.2 does include support for the toggle buttons so I decided to install the beta.
When I installed the beta, it did indeed add the toggle buttons. It also fixed the first two issues I mentioned BUT …
… it completely broke iOS support in Visual Studio 2013 (we need to keep in mind that Xamarin.Android 4.10.2 is still in beta). I could no longer open or create iOS projects (remember it’s Android support that I updated). Unfortunately reinstalling Xamarin.IOS did not fix it. I ultimately had to completely uninstall all of Xamarin then reinstall from scratch and live without the toggle buttons for now.
Moving on from the Android UI designer for a moment, I also ran into problems with the wizard-generated Android project in that it’s naming the Android resource folders incorrectly.
Notice that the folders under Resources (Drawable, Layout, Values) are all capitalized. That’s not supposed to be the case [ excuse the pun 🙂 ]. The Android platform doesn’t like that. Those are supposed to be all lower-case. I had to go through and manually rename them. Not ideal but not the end of the world.
BTW: Fixing those folder names had a nice side effect: It resolved the problem with the string resources. With those names fixed, the string resource values now display correctly on the device design surface (thanks to James Montemagno at Xamarin for his help on this one).
You can follow the steps I went through working things out on the Xamarin Forum.
After working through all the Android stuff I setup all of the iOS pieces which include setting up a Mac as a build server. The setup process went pretty smoothly. I then ran the wizard to generate an iPhone Hello World app, did a build and immediately got 2 build errors and 1 build warning.
And with that I’m calling it a day.
I must admit, I expected an unchanged, wizard-generated project to be error free. 🙂
To not blow things out of proportion, we want to keep in mind that none of the issues I’ve mentioned are show-stopping. They’re basically annoyances and all fairly easily worked around.
We don’t want to lose sight of the fact that Xamarin is solving a very hard problem. Android and iOS are incredibly different platforms with many of their own nuances and complexities. Then on top of that, Xamarin has to integrate into Visual Studio (a complex IDE) and interact with the iOS toolset running on a Mac. Many, many challenges to overcome.
Working in a brand new environment is always a bit stressful. For me, the best way to have that stressed relieved is for the environment to all work smoothly which didn’t quite happen in this case. That said, I have a workable environment and although I do need to apply some workarounds, they are all fairly easy to deal with.
I’ll dig back into things tomorrow.
Update: I’ve posted a follow up to this post.
I’m not big on self-promotion but I’ll make an exception as this is an exciting day for me…
My book Creating Dynamic UI with Android Fragments received its first user review on Amazon and its a 5-Star Review
This book is just what I was looking for. The three pieces I was having issues with were static vs. dynamic fragments, dialogue fragments and backstack management. This book covers all three of these in a manner that has really cleared up my understanding and improved my application design as a result.
Thank you to kbp135 – Here’s the link to the review.
And just in case you’re wondering … the reviewer is not someone I know 🙂
Checkout Creating Dynamic UI with Android Fragments for yourself. I’d love to hear your feedback.
Also checkout Jim’s Android courses at Pluralsight.
Jim’s Android courses on Pluralsight
According to recent data, senior Android developers average $131,000 per year versus $121,000 for the same skill level on iOS.
That’s some pretty serious cash!
So what are you waiting for … clearly, it’s time to get your Android skills tuned up! 🙂
The full story is available in this Tech Week article.
Checkout Jim”s Android courses on Pluralsight.
Jim’s latest book, “Creating Dynamic UI with Android Fragments” is now available on amazon.
Part 4 of my four-part series on Android programming for developers with a .NET background just went live today.
This course delves into the unique features of the Android platform and how those features and the related components affect the way apps are created.
I hope you’ll check out this course and the whole series if you haven’t already seen it. I think you’ll be happy you did.
Here’s the complete series
Android Studio makes adding swipe navigation to your Android apps easy through the “Scrollable Tabs + Swipe” option of the Navigation Type selection in the New Project Wizard. Choosing this option works great as long as you have a static list of screens that the user “swipes” between.
The way swipe navigation works is that each screen is represented by an instance of a Fragment-derived class. These Fragment classes are then managed by a PagerAdapter-derived class which makes them, in effect, a scrollable list. Passing that PagerAdapter to a ViewPager presents that list in a way that the user can use a swipe-motion to move between screens.
The code generated by Android Studio provides a custom PagerAdapter class that derives from FragmentPagerAdapter. Basically all one has to do is override the getItem method and return the desired Fragment for each screen position (you’ll also need to override getCount and getPageTitle but those are super simple). What happens though is that the FragmentPagerAdapter class is designed such that once a Fragment instance is returned for a given position that Fragment is permanently in that position. Once this happens, you can, of course, make changes to the contents of the Fragment but there’s no way to provide a different Fragment instance for that position which is often what’s necessary.
The comments in the generated class indicate that using FragmentStatePagerAdapter instead of FragmentPagerAdapter as the base class allows for more dynamic management of the Fragment instances. Reading the FragmentStatePagerAdapter documentation indicates that we can notify our FragmetStatePagerAdapter instance of a change in the list of screens (in other words that we’d like to use new Fragment instances) by calling the notifyDataSetChanged method. But that’s only part of the story.
Once you call this method what you’ll normally see is that screens that were previously visited still have the old Fragment instances but screens being visited for the first time have the new Fragment instances. If you have a large number of screens and scroll back and forth between them you may see some of the older screens eventually show a new Fragment instance.
Not really the consistent user experience we’re looking for 🙂
What’s happening is that FragmentStatePagerAdapter is trying to be efficient and only create new Fragment instances when necessary. To determine when to request new Fragment instances after a call to the notifyDataSetChanged method, FragmentStatePagerAdapter calls its getItemPosition method to see if an existing Fragment can be used in its current or possibly a different position without having to recreate it. What we have to do is tell the FragmentStatePagerAdapter instance that we don’t want to use the existing Fragment instance.
To do that we need to override getItemPosition as follows
public int getItemPosition(Object object) {
// Causes adapter to reload all Fragments when
// notifyDataSetChanged is called
return POSITION_NONE;
}
By returning POSITION_NONE we’re telling the FragmentStatePagerAdapter instance to discard that Fragment and just create new ones for every screen position.
To summarize what to do, here’s the list of steps…
And with that, you have the ease of swipe navigation with the ability to reload Fragments instances as needed
Adapted from Jim’s Pluralsight course Android for .NET Developers: Adopting the Android Mindset
Checkout Jim’s latest book: Creating Dynamic UI with Android Fragments
Jim Wilson (a.k.a. hedgehogjim) 