Horrifying. That about describes my first art class. As a computer science major with virtually no art experience I was surrounded by students who had devoted nearly every waking moment to drawing, painting, sculpting, and bending metal into non-functional shapes.
We love tools that help our clients save time,
Choosing the right tech stack for a project can be difficult. There are many factors that weigh in on which tools to use. Your team's proficiency in a language, available frameworks, hardware requirements, existing components, and many other variables help shape this decision.
For a recent project we build a WPF application to run on the windows 10 platform, but we were hoping to take advantage of some of the new hotness that didn't exist in Windows when WPF was created. Enter the Windows Desktop Bridge, or Project Centennial depending on how you google it.
- Maximize UI performance by reducing excess render cycles associated with traditional view nesting
- Increase maintainability and readability by removing ceremony and keeping layout code concise
- Simplify usage of RelativeLayout while increasing its power and abstracting away its quirks
In this post I’ll briefly explain what it is, then get into why we need a new UI framework in the context of each of the above three goals. I'll finish with limitations, some history, and how to get started.
We previously walked through how to get started with a cross-platform Xamarin.Forms project, but what if we started with an Android app built in Android Studio? Here's a way to re-use a lot of our Android code and layouts with Xamarin.
"I'm starting a cross-platform mobile project. What problems should my team solve before we begin?"
What an enlightened question, I thought.
The individual standing next to me at a local developer conference had a software architecture background. He clearly understood that laying a solid foundation at the outset of a project can either spell success, or result in project delays, massive technical debt, and quagmires for even rudimentary tasks.
As a consultant of nearly two decades I've seen all too well the results of poor project planning. After 36 individual projects, eight of which were mobile, 4 of which were cross-platform mobile, I felt comfortable answering the gentleman's question with plenty of first-hand knowledge to back it up.
This post answers the question of what problems a mobile team should consider at project outset. It's expressed in real world mistakes and the resulting consequences as I've witnessed them.
1. Overemphasize One Platform
How hard is it for a .NET developer to build a Fire TV app with C#? With the right tools, it's pretty easy; a Fire TV app is just an Android app optimized for viewing on a TV.
Since .NET's inception, my language of choice has been C#. For the C# developer, Xamarin is a useful tool for deployment to more than one platform, such as Windows, Android, iOS, or in our case, Fire TV. With Xamarin, we can build one set of back-end tests and code in C# and share the same code among all of those platforms.
Xamarin.Forms provides even more shared functionality: with Xamarin.Forms, we can even build our views using a set of controls common to all of our target platforms.
Why would you want to build apps for Fire TV? Well, Roku may be the current leader in the market for streaming TV boxes, but Amazon Fire TV's share of the market isn't too far behind at 2nd place based on data collected from comScore as of December 2016. And like other Amazon Fire OS devices, Fire TV is built on top of Android, so we can leverage most of the existing Android libraries and tools to build our TV apps, making them useable on both Fire TV and Android TV devices!
If you've used a lot of Fire TV apps before, you may have noticed many of them have a very similar look-and-feel. This is because many (if not all) of them have built their apps on top of the Android Leanback support library, so they usually end up looking similar to this out-of-the-box design:
What's the best way to keep secure data in our local Android or Fire TV shared preferences? Well, don't do it. If someone's curious enough, it's not too hard to dig into the Android file system to look at a particular app's preferences.
What could we do to keep curious users from breaking our app by tampering with the settings? Perhaps we could make it a little less convenient to inspect or modify the settings.