00:00:14.920
Hello, my name is Sarah Allen. I go by Ultrasaurus on Twitter and pretty much everywhere else. Today, I'm going to talk about cross-platform mobile applications using Ruby.
00:00:20.400
I apologize that I don't have any photos of hippos or really great artwork to share, but my hair is the color of Jessica Alba's eyeshadow, so I hope that helps.
00:00:27.119
Being a mobile developer is a lot like being really into getting tattoos. You’re either really motivated to achieve that end result or perversely into an exquisitely painful experience.
00:00:37.840
This is the mobile landscape. These are the major platforms, and for each platform not only do the desktop applications come with their own set of APIs, but almost each platform necessitates a different programming language. It's a crazy development landscape, requiring you to learn a different toolset and apply different languages with every platform.
00:01:15.200
In this talk, I'm going to share with you my experience using Conference Driven Development, or CDD. I decided to give a few talks on mobile Ruby development and build an app that would be the same across different platforms, and I will open-source the code.
00:01:27.680
I know the network is quite bad here, so I’ll show the code at the end of the talk. If you want to check it out, it's on GitHub at Blazing Cloud, under the project named Rhodes Ruby Conf. This is a specific application I thought would be fun, even though I don’t think anyone here has participated, but I’ll show it to you on three different phones.
00:01:45.520
The usual process for writing an app involves writing the code, releasing the app, and having people use it. However, you want to think about this process backwards. First, consider what you're going to build and how people are going to use your app. You also have to think about how to release it, which is a little more complicated on mobile devices than it is for web or desktop apps. Lastly, you'll figure out how to build the code. This is the order in which we’ll discuss apps today.
00:02:19.760
You all know Ruby, so I am going to show you the code last, but I will share some important concepts to think about when doing mobile development.
00:02:25.280
Who here does mobile development? There’s a smattering of people. Some of this will be new to you, while you may have heard of these topics before. I believe that mobile development should not feel like body piercing; rather, it should be akin to creating a custom-tailored suit.
00:02:58.640
I think that the tools I will describe today can help you recognize common patterns in mobile development, allowing you to replicate them. These patterns include design styles as well as technical details for which we can develop reproducible tools—ways that we aren’t able to do as effectively today.
00:03:30.319
Many have talked about the aspiration to 'write once, run anywhere,' but I don’t believe that’s going to happen in my lifetime. I have worked on many of these platforms and found that you must develop for each platform and design specifically for each one. If you're using a good toolset or working with smart developers, then you can refactor the code to maintain functionality across platforms.
00:04:01.680
Next, I want to show you the user experience of this app, which I will demonstrate on my device.
00:04:12.400
You can see here a picture of my dog. There are pictures of animals in my talk. This is the iPhone app. How many people here have an iPhone? I would say it's the majority in this room.
00:04:23.600
The iPhone is gaining popularity and is likely more prevalent in this crowd than it is in most parts of the U.S. It's important to note that with the iPhone, you get a touch screen and I can scroll through this app.
00:04:37.760
This app is relatively simple; it includes the conference schedule, tabs for registered attendees, a map, and an about box all utilizing the regular tab bar control you will typically see on most iPhone apps.
00:05:11.200
Now, I have a Nexus One, which also has the same app. You can see that it has the schedule and a touch screen interface, similar to the iPhone, with tabs across the top that functionally act the same as they do on the iPhone.
00:05:22.800
On the BlackBerry, things are a bit different. While you have a schedule, scrolling is done with a scrolling wheel instead of a tab bar because BlackBerry does not have a touch screen. However, it does have a menu that still allows the selection of different screens that behave like a tab bar. This interface may look peculiar to iPhone or Android users; however, if you are familiar with a BlackBerry, it may feel quite familiar.
00:05:56.480
What’s key here is that although these phones differ greatly in design, their usage from a user perspective is generally the same. Once you’ve used each phone for a few applications, you grasp the operation quickly. The differences in development experiences across phones are relatively minor.
00:06:13.880
Historically, in the past few years, as application development has surged, individual developers have often thought about platforms and their respective audiences. However, as we move forward and more individuals gain access to mobile phones—over half of the world's population now owns a mobile phone—it is increasingly evident that businesses are considering moving their services from the web to mobile platforms.
00:06:54.240
Thus, the brand experience must now transcend the platform. It's essential to think about your design independent of the platform you intend to deploy on. This mindset is beneficial to developers as it encourages cross-platform thinking.
00:07:27.119
Another point worth mentioning is that these devices possess more power than the computers I first learned to program on. However, from a design and development perspective, these are not just mini desktops. It's vital to consider that phones enable fundamentally different experiences, utilizing unique features such as geolocation, built-in cameras, constant connectivity, and access to contact lists.
00:08:04.560
Moreover, unlike traditional desktop applications, mobile applications do not adhere to the same privacy concerns; it is assumed that applications can access all device capabilities, providing greater freedom for development.
00:08:41.760
After you've considered your application’s design, the next step is to strategize your release. For this application, I launched it on iPhone, Blackberry, and Android. As you may know, iPhone applications can only be released on the Apple Store, while Android and Blackberry applications allow for greater flexibility in terms of distribution.
00:09:03.440
If you go to the link mobileruby.heroku.com, you’ll find a link to the Apple Store, along with direct links to access the Android and Blackberry applications. If you have those phones, you can navigate to those links, and the app will install automatically.
00:09:44.880
The Apple Store experience is not so transparent. First, you will sign up for an Apple ID, fill out a form, and provide a legal contact before enrolling. After signing up, you receive application development certificates, a process that may take anywhere from 24 to 48 hours.
00:10:15.319
You must complete this before releasing your application. Once accepted into the Apple Developer Program, certificates will be generated through a convoluted process; although it’s well-documented, it can be difficult to find the exact steps you need to follow.
00:10:37.520
Even while utilizing cross-platform tools, you're likely to end up needing to open Xcode. Row Mobile now has a rake task that simplifies this process; however, you’ll still go through steps to insert your signing certificates, build your app, and submit it to the store.
00:11:09.200
However, the Apple Store approval process can be lengthy. For reference, my first application submission took three days, which was record time, because approval generally takes weeks. With minor subsequent updates, I found that they took about 24 hours for the first and 8 hours for the second.
00:11:46.800
On the BlackBerry side, you also need to register for key access. The Apple Store charges $99 for individuals and used to charge $300 for companies, but this has changed. On Blackberry, you need to pay a $25 fee for keys that may take an unspecified time to be issued.
00:12:32.480
Once I received my keys, I needed to install them on my Windows machine via Parallels on my Mac, and then using Row Mobile, I could perform rake tasks to create files for release online. If intending to publish to the Blackberry app world, you have to apply for a vendor portal, which requires a $200 payment.
00:13:07.920
Android is a bit easier in terms of key generation, as you can do this on your local machine and, once again, using Row Mobile, you can generate an APK file for deployment. To publish to the Android Market, you must fill out a form and pay a $25 fee. Be aware that payment methods differ between Blackberry and Android, with PayPal used for Blackberry and Google Checkout for the Android Market.
00:13:51.200
As you begin deploying and publishing your app, it’s wise to sign up for these programs ahead of time, as the approval process may take an indeterminate time.
00:14:23.200
Now, let's dive into the fun part—writing some code. I’ll share a bit about the Row Mobile platform, which is how I develop cross-platform mobile applications using Ruby.
00:14:37.279
Rhodes is the Row Mobile client-side framework following an MVC pattern, common in web application development. It's crucial to remember that while it borrows concepts from web techniques, it does not operate through the traditional request-response cycle online.
00:15:03.760
You define your application's UI using HTML and CSS, which builds the screens of your mobile application. When a button or link is clicked, this initiates a request directed to your Ruby controller code on the device. Optionally, it can then communicate with the data store, known as ROM, which connects with any database on the device using a unified API.
00:15:51.680
You can fetch data, render it through ERB files into HTML, and this outputs the next screen for your application. This familiar cycle mirrors processes used in web development, which many of us are accustomed to.
00:16:14.240
In many ways, building a Rhodes application resembles developing within a Rails context; while the details may vary, core principles remain similar. To walk you through the application structure, I will start by showing you the tab definitions.
00:16:54.560
In this particular app, the data structure is defined as a hash, containing the label for each tab, along with associated icons and actions. This specific action is a URI that maps to my file structure for the application.
00:17:34.640
Next, we'll look at the map action. The map calls the app person map within the person controller, navigating to the map action. Here, it sets up an instance variable for the 'people' and retrieves data from the backend web service, which happens to be a Rails app.
00:17:55.760
This web service has a corresponding person data structure that facilitates generating a person index page populated with various attributes. The initial version of this app predated the specialized custom native map functions working on Android, which previously relied on DHTML for display.
00:18:32.640
You would find that iPhone and Android share the WebKit browser, akin to Safari, providing powerful capabilities for implementing JavaScript. Utilizing this framework allows for embedding ERB files alongside JavaScript, creating impressive mobile experiences.
00:19:09.680
Moreover, by implementing a native map view API provided by Rhodes, you can abstract platform differences, creating a uniform mapping experience across devices. Utilizing this, you can effectively map people objects to specific points on the map.
00:19:51.919
Next, I would like to discuss something significantly distinct from web frameworks. The Settings Controller is used in this app’s startup sequence. When you create a default Rhodes app, it generates a settings controller that allows user login. However, this app performs an automatic login upon startup.
00:20:31.520
This process involves a series of asynchronous events that begin at the start action. This requires configuration using a file that designates a start path for the desired controller action.
00:21:07.200
Upon startup, a check is performed to see if the user is logged in. If they are not, the sync engine will initiate a login procedure directing to the server. Conversely, if the user is already logged in, the application will navigate to the designated app route.
00:21:56.640
The sync engine presents a callback which invokes the 'login callback' upon receiving a response from the server. After successful login, it proceeds to 'do sync'.
00:22:13.440
The sequence of controller actions linked together forms a more event-based programming structure, more akin to that used in UI development rather than traditional web development.
00:22:55.200
I will stop here and open the floor to any questions.
00:23:06.560
One attendee asked about the costs associated with the iPhone developer certificate and BlackBerry fees. I didn't touch on the Rhodes cost and licensing, which should also be addressed.
00:23:42.560
To clarify, while PhoneGap is an appealing option—being free and having robust support—I find it more challenging to adopt due to its rapidly changing tools that can complicate integration processes.
00:24:13.440
While PhoneGap is excellent for wrapping HTML and JavaScript into applications, I've noticed the tools can lead to frustration with consistency in development methods.
00:24:33.920
The Rhodes framework has its limitations, with the licensing being GPL, which means you must open-source any code you develop, unlike some other frameworks that provide more flexibility. For Rhodes, the client-side framework costs $500, and the synchronization server is $5,000—pricing that escalates depending on your needs.
00:25:05.600
If you do not require synchronization, you can avoid paying for it. For developers just seeking to create a simple mobile app, this might be a more cost-effective choice.
00:25:32.640
There were further inquiries regarding the state management of the application, specifically about the loading times when tabs are navigated. This delays in loading may stem from the app design; although it is intended to refresh data, we must ensure user experience is smooth and feedback is provided during that process.
00:26:42.080
Issues also arose related to submitting changes through the app and seeing immediate results; the app necessitates time to communicate with the backend server to fetch updated data.
00:27:03.680
This behavior indicates that enhancements should include error handling to inform users of the status of their interactions, especially concerning connectivity issues with mobile applications.
00:28:06.240
There was a follow-up concerning the device's dynamic API calls, noting that it often looks like many frameworks but does not operate through traditional methods that require active requests. The answer is that it leverages local data when possible, generating a more integrated experience.
00:29:22.080
I did hear about Rhodes VM disabling eval due to Apple's restrictions. Generally, this shouldn’t significantly impede the kinds of gems you can access unless you specifically require dynamic script implementations.
00:30:06.560
I acknowledge that until recently, support for gems was limited within Rhodes’ framework, but recent updates have begun facilitating additional libraries on your devices.
00:30:18.240
Performance is a notable topic; while you can expect a slight decrease due to utilizing a framework, it ultimately balances out due to the ongoing improvements in tools and methodologies available.
00:30:33.440
I appreciate your participation and thank you for your questions.
