Tip:
Highlight text to annotate it
X
>> I'm pleased to introduce Adam Blum. He's going to talk about Building Mobile Apps on
various phones that all use a framework with Ruby which is very exciting idea for me, and
take it away Adam. >> BLUM: Thanks, John. So today I'm going
to talk to you about how you can build mobile apps for pretty much all smartphones, iPhone,
Android, Windows Mobile, BlackBerry, all writing them one time using this framework that we
have called Rhodes. So, real briefly, the company that we've released Rhodes is called
Rhomobile and our mission is to mobilize applications very quickly with a great user experience.
And the basic ideas to provide the high level productivity and portability of web programming
that I'm sure most of you here are used to using but still provide that optimization
and offline capability of "native mobile apps" that you might write in the native STKs whether
the objective [INDISTINCT] for the iPhone or Java for Android and may call this available
open source for rapid adoption by developers. So quick background on this, as you know smartphones
sales are exploding. There are five major smartphone operating systems but one of the
problems is that the growth leaders are the installed base laggards, so what would you
target? You'd have a hard time, sort of building just for either iPhone or Android. And the
other thing that's happened is that native apps are sort of won the day, right? Users,
sort of wants stuff stop that runs on their phones and doing, sort of interactive, you
know, apps where people are creating information and doing that from mobile web browsers is
just something that users are just not interested in doing today. Probably if I gave this presentation
a year ago people would say, "Well I'll just," you know "build my mobile web app." And I
think--now when I talk to developers about this I say, "Well, this is not the right session,"
you know. "Go." Even though we're all about HTML for productivity, it's HTML to build
apps that run natively on the phone whether you're connected or disconnected. So, that's
what we let you do with Rhodes. We let you build the app quickly in HTML and Ruby. You
write it once and it runs on all smartphones. They actually think that you--you'll generally
write just like with the goodrails app, you'll write most of your UI or do most of your UI
customization in HTML because we have an app generator that generates basic scaffolding
of an app. And most of our developers tell us they spend most of their time just playing
with the Ruby templates, the A or B HTML templates. Rhodes is also focused on synced local data.
So does that mean that you can't write stuff with Rhodes on the phone that, you know, reaches
out and grabs [INDISTINCT] and, you know, using the non HTP libraries. And you can do
all that but we provide this infrastructure, this server called real synced and a synced
client that let you write your app so that your development experiences that your writing
till data gets local on the device. You have an ORM and it just looks like the data is
local and that whole problem of how you get data from the backend to the--to the device
is something that, if you'd like, Rhodes can sell for you. We also want to exploit device
capability. So it's all about writing rich apps, right? That's another reason why the
mobile web approaches is not as good because you want to be able to use the GPS that's
on your device, you want to be use the camera and the video and the local contacts. These
devices are very powerful that you want to--you want to use them. So, we allow you to that
as well. It's with a combination of an extended set of tags but also Ruby libraries, so, sort
of whichever you need for your app. If you want to just have the location, the GPS location,
you can just put a geo location tag in your HTML templates. If you need to do something
more sophisticated like look at the latitude or longitude and do some kind of computation
on it and then conditionally do things, then we have Ruby libraries that give you access
to that as well. And this is all available open source, it's up on github.com/rhomobile
and that's real time. So it's always current with--with whatever our [INDISTINCT]. It's
not like snapshots. If you don't see a check-in--multiple check-ins everyday then, you know, ping us
and say "Get back to work." So the two components that you'll generally use in your apps are
Rhodes which is a microframework for building locally executing, natively optimized mobile
apps. You'll basically run an app generator for the objects that you care about, and then
you'll edit HTML templates. Then you'll just do a build and then you have the functioning--we
have [indistinct] that do builds for all of the major smartphone [indistinct]. Along the
way we had to build the first mobile Ruby implementations for all of these different
platforms. The one exception is Symbian. There is a Symbian Ruby that was funded by the Symbian
Foundation and a company called Pragmaticomm that we worked with, built that for the Symbian
Foundation that is actually out there. It's available open-source but they don't--unlike
us they don't keep every check-in live so--like the current version is not actually available,
but we started with errors and then we've made a bunch of optimizations to make it work
better on smaller devices. Just on the issue of the Ruby implementations, John was sort
of asking me the question like, you know, how can you possibly--Ruby is pretty big,
how do you fit her in all these devices. And this is where the framework gives us an advantage.
The important thing is that, the code that you would write in the framework, right? When
you're sort of working within our MVC framework, the code that you would write within that
has to work. It's not that any Ruby code that you could ever think of has to work. So we
don't have every Ruby gem in there, like we don't have the XML support in there. Could
you add that? It's all open-source, right? And the framework just gets compiled into
your application so you can absolutely pull all the gems you want into your project. We
don't stop you from doing that, but because we have a framework, we can start with a very
stripped down Ruby implementation. Because--and that handles 98% of what programmers need
to do. And--but if anybody wants to take it and says, "Well, I really--we have a--I'm
an adjunct [INDISTINCT] email and some of the students there want to use Rhodes and
implement XMPP to do real time communication and they want to add that--those libraries,
there are some Ruby libraries for this. And we said, "Great and just do it," you know,
would we take that back and put it into the framework probably unless there's a real compelling
case to do that. So and then the other piece we have is RhoSync which is--it's a sync server
that's focused on web service data. It's focused on Apps that expose some kind of [indistinct]
web service that you would connect to. So--and that could be, nowadays that's basically any
app. But it's unlike a lot of other previous sync servers like Intellisync, its either
they're all about synching databases which ironically enough is sort of a harder problem
in general. So it's a little simpler now with all these web services that are exposed but
there are also some things that make it harder and Intellisync was actually discontinued
because they never made the shift, you know, to being optimized web services but--so that's
what RhoSync does. What--all you really need to know as a developer is, if you want to
have something that will sync to a backend, you need to implement one Ruby class. It has
six methods: log-in, query, create, update, delete and log off. And whatever your backend
exposes that you want to get to, as long as you can write Ruby code that--within those
six functions, it'll just work. So this is the architecture of what we've been talking
about here. So, your app is all these gold things. So you have a controller which you
would expect right in an MVC framework and you have a bunch of HTML templates, they happen
to be ERB files. And then on the backend--and nobody is forcing you to use RhoSync. If you
want to do all your own real time data capturing and retrieving, you can do that. But if you
want to use RhoSync, the sync app, you write this what we call a source adaptor, and that's
this class that has the six methods. And so in this example I had, you know, an app that
has like two objects in it and that's another thing that Rhodes apps are sort of good for.
If you want to sort of do, like a mobile mass shop where you're maybe getting data from
different sources, the best apps I've do quite a bit of that. You know, they'll get interesting
data from various places. So in this example there is, you know, a couple objects and so
there's more than one controller free to these objects, some templates for them and then
source adaptors. So--and then we provide all the things in red. So we have these Ruby interpreters,
we have a simple ORM, it's called RAM. And so what it is, it's just a very stripped down
object relational manager. If you look at things like Hibernates or--even active record,
there's no way, I mean, if active record could have fit on the device we would have used
the active record. But not only is active record too big but so its data mapper and
so its [INDISTINCT]. They're just all like--at least in order of magnitude too big. So RAM
is just this very stripped ORM. And then--of course we have this RhoSync client that knows
to talk to the RhoSync server and sends its data back and forth to the server very efficiently.
We use JSON to do that. And so it tries to optimize, you know, just getting the data
it needs from the server. The server sort of keeping a cache of what that device should
have and then trickle synching it as appropriate down to the device. Now there's another intriguing
box here, people usually ask about like "Wait, you have a web server there? Why do you have
web server there? What's--why is that red box there?" So, anybody have any guesses why
our web server is there? It's all about local data. Why would we have a web server in the
framework? So, the reason why is we don't want to have to handle all the--we want people
to write in HTML because it's familiar, but we don't want to write an HTML renderer for
every device. So what we do is we use the browser component that shifts with whatever
smartphone OS is there. And the good news is that in 2009 you've got really good embeddable
browser components for all of these platforms and nobody can tell when--once you build your
app by the way, that it's written with that browser component. We'll talk about it later.
We do some styling with--if anybody has ever seen iUI which is a Joe Hewitt who's now at
Facebook, wrote this library so that you can write HTML but it looks like a native iPhone
app. And so we've taken that sort of basic approach, extended it, made it even more optimal
but then did it for all the other OSs. So the net result is, even though there's a browser
there, you can't really tell. It looks very close to a native app. But all of those browser
controls expect to be talking to a web server. So, that's why we have--we have a very, very
lightweight stripped down web server within there. And then we have another piece we shift
with SQLite. And we have a bunch of synched local data sitting on top of SQLite. So those
are the third party components. So we ship with the couple sample apps, one for a SugarCRM,
they're open-source CRM, sort of sales management package. So we ship with that sample, we ship
with one for Siebel Field Service. And there's a number of third party apps that are coming
out now. There's a company called Carry the Day, it has a product called TrailGuide which
is a mobile interface to Basecamp. It's a very nice app. It's our now. VDG Group is
about to release a product called Mobile Lighthouse. Lighthouse is a hosted bug tracking system,
and so this is a mobile interface to that, also written with Rhodes. And Hampton Catlin
who is pretty prominent Ruby developer, he wrote Haml which is a really nice templating
system. We don't support. He's actually not suggested that we do the heavier weight; we
use generic ERB templates which is a simpler templating mechanism. But Hampton Catlin had
written an entire iPhone app for the Wikipedia. It was one of the top selling phones in the
app store and then Wikipedia basically bought him and his app and said "We wanted to be
free." So then he rewrote the whole thing for the iPhone and then he read about our
stuff and Ruby inside and said, "Oh, I'm going to throw--throw that away," which he did.
He actually pulled it off of github and he rewrote it in Rhodes. And now it runs on all
devices. So, let's talk about the overview of what it means to build Rhodes app and then
we'll go and actually in write one. So, the first step is--as in with most rails app,
you sort of want to start with your data, right? What's the data that you're working
with? You don't have to, you can build your Rhodes at first, make it run locally and then,
you know, decide what data you're synching with. In general, we think it doesn't work
quite as well that way, its better to start with what the data is. So we recommend that
you create what we call a synch source. So you write your source after code, we give
you--we give you a test interface to do that so you can just test it from the web interface
and make sure that you're bringing back all the data. Anybody that's sort of interested
in sync, I've actually written most of the code for RhoSync and we do a number of things
in RhoSync that are sort of a, I think better ways of doing sync but I'm not going to drill
into those now. We can talk about it later if you want. Codes are all up there, you can
take a look at it on github. Then you want to generate your App, your actual Rhodes App
that runs on a client. So you'll run rhoGen and it generates your ERB templates and your
controller and then you'll just edit the code, edit the HTML and then you do a build and
you have a functioning app. So let's try it, shall we? So, okay, so, what I'm going to
do is say rhogen app and I'm going to call it my new app. By the way, if you're not sure
of the usage just say rhogen app, and by the way, rhogen is a gem, like any other gem.
John and I were talking earlier about how gems are such a great way of getting functionality.
Far better than things like CPAN and Appget, et cetera, it's such a great way of getting
developer tools. So, you just say gem install Rhodes and you'll get Rhodes installed on
your device. So that's where we got rhogen from. As long as you've done gem install Rhodes
you'll have rhogen and it's says "okay, app options", it basically just wants a name.
So--and there's a variety of other options but I'm just going to say rhogen app, my new
app. Okay. And you can see we've got a bunch of files. This is hard discipline, standing
still. So we have this app directory and we've got a bunch of ERB templates in there, we've
got a config, our B file that lets us configure the app. And we've got this public directory.
It should seem very familiar, those of you that are rails developers. I understand that's
perhaps few and far between here. But--so what we'll do is--now what we want to do is
we want to generate a model. We can--we probably will want to create multiple models, right?
But let's start with one. So I'm going to write this little contact manager app and
I'm going to call my model contact. Well, let's first look at rhogen model, just to
look at the usage. So it says, "Okay, what you want to do is give us a name, a source
URL, and a source ID? Now if I had done what I've recommended to you guys which is, you
know, define your sync source adaptor. What I would do is I would just take the source
URL, the URL where that sync source adaptor is exposed which should be like, on my test
machine will be like, local host, you know, apps, local host my app, you know, source.
And I would take that and supply it. What I want to do is show how easy it is to create
a simple, you know, off line app which I don't think you've seen yet. I have built something
from scratch, like it did the whole sync. You can also create something that isn't necessarily
about sync at all. So, I'm going to say rhogen model, like--actually let me go into the--my
new app directory. Okay. Now I'm going to say "rhogen model, contact." And then I'm
going to say "no source URL" but I'll give it a source ID and I'll say like "name , phone",
okay? And now I've got the model, again, as a rails developer, you could, you know, you
still have a model and your scaffolding code and that's what we have. So now, just fire-up
my trustee textMate and we'll look at our new app. So this is our app. You can see that
we've got a top level thing here and then we have all the scaffolding to go and deal
with editing, creating new contact records. And then we have this controller here which
is a Ruby file, looks very similar to the typical rails, scaffolding for doing basic
crud on objects. But there are some differences, some of the URL differences are--the URL convention
like Getz and, you know, when--what do you do for delete is a bit different than you
get with rails. Now any--those of you that are mobile developers, any guesses why? It
would be great, obviously if we could. We would just follow all the rails convention
for URLs. So the reason why is, these mobile browsers are all over the map in terms of
the actual rest verbs that they support. Some of them don't support deletes, some of them,
you know, do put in unusual ways so we can view just closely as we could to the rails,
sort of rest conventions, but they're not quite exactly the same for that reason. That
is also the part of the value of a mobile oriented framework. So, I don't really have
to do much here to get something useful. The first thing I want to do though is just provide
a link to this object, the contact object. By the way, our [INDISTINCT] is about to release
and you won't actually have to--the idea is that we built our app first and then we build
the models. So now we have to go, like tell our app about our model. There's actually
a Lighthouse issue for [INDISTINCT] where it will actually--the model generator will
modify the app homepage. But generally, you're going to want to edit this home page and do
cool branding stuff with it. And you can use, you know, your familiar HTML, JavaScript,
CCS toolkit to do that. So, I'll say something, like contacts here. And that's it. You know,
this is just--just HTML. So, you can, sort of go as far as you want with that. And notice
that the HTML is very generic here. It just gives tags, right? And there's a reason for
that. Any reason why, I mean, notice that there's no sort of like, styling, like write
in here. The reason why is we wanted--we generally want to create very generic HTML here and
then we ship with the framework all of the styling in libraries. So, we have--we used
iUI, its 90% iUI to sort of style all of these div tags so that it looks like, you know,
a native iPhone app, same thing for windows mobile and Blackberry. And we've done our
sort of best attempt at, you know, making something that's native. And this is an area
where we know the community will do better. We've already got a number of community submissions
and I know when the styling for things like Symbian, the community is going to do better
than we would. So, let's go ahead and just do our built now. So, we're in my new app
directory and let do a [INDISTINCT] and you can see all the cool tools that we have. And
so we have the ability to build for Blackberry, iPhone, Windows Mobile and you can--you can
just build or you can build and run for all of those. Now, notice any glaring omissions
on that list? So there's no Android build right now. And in fact, that sort of the missing
piece that's--we're not scheduled to release until March 10th anyway but, the team is furiously
working on making sure the Android has to be, you know, at a par with everything else.
So, it actually does run, it runs in devices pretty well. It runs really slow on emulators.
That's why I'm not demoing it today. And--but we don't have the automated built. We have
a step by step--if you go out to our Wiki; we have excruciating step by step guide for
all of the environments. But most people just use the Rig scripts now and so we'll have
the stuff for Androids soon. So let's go ahead and do a build and run for iPhone. So, you'll
see, it fires up my emulator and I've got--and by the way, if I had my device connected it
would just launch that off as well on my device which is a little bit harder to demo from.
We shift with it--obviously, you can put your own icons on it. It just happens to be the
icon that we shift with. The other thing I wanted to emphasize about this built process
is it's just our framework around your app, right? Like nobody knows that it's Rhode [INDISTINCT],
right? So it's all just compiled together, even though it's cooler now that I can do
the Rig scripts, when I do, I used to--the demo that you saw, I was doing my build from
Xcode. So it made it very obvious, right? That it's sort of just your app and we're
effectively just some libraries. I think now with this black box that made, you know, with
just the Rig scripts, its not that easy necessarily to tell that this is just your funct running
app, you know, you can just--it obviously won't have the Rhodes icon. But it is indistinguishable
from any other app. So you see, this is the App that we created, it has a contacts list.
I can say "create a new contact", give my name because all the basic crud is built in.
Obviously, you would want to go in and change the styling or, you know, just the layout
of the fields or add whatever you want. So now I've got Adam as a record and I've got
a link to new contact and, you know, you'll party on this HTML files and edit it to your
hearts content and create the user experience that you are looking for. Okay. So that's
sort of writing the whole Rhodes app. There's this other thing of defining a RhoSync source
and as we mentioned, you're just really creating a handful of methods, you're creating a log
in method. So, log in to whatever your backend system is. You can create a query method that
retrieves and reads object from the backend source. Our tutorial tells you what you have
to do to write that query method. There is--basically that query method brings it back into--typically
you're getting it back as XML. Then we sort of separate the part from--you've done the
query and now you want to like, populate the cache on the server. The form that we cache
it in is what we call object attribute value triples. The objects are called object values
and--we have generic code in that sync operation that does it for the vast majority of your
stuff. So you'll see it, sort of takes apart what you've gotten back and it creates this
object attribute value triples that can represent, essentially, arbitrary data. And one of the
things that we do, and because this is a Tech Talk, I'll talk more about it than I generally,
like you haven't heard me talk about it before at other meet ups. So, one of the things that
we do in RhoSync that's unusual is--so if you look at any of these other sync servers
that have been out there, like Intellisync, and Motorola had this product called Starfish.
And what they all do is they, they sort of have these data bases here and they figure
out the data they needed to get and they serialize it over the wire in some equivalent of object
attribute values, right? Because it's a generic form, they can handle sending anything, right?
The object ID in question, you know, an attribute like the user's address and then the value.
And then they get on the other side and they sort of put it all back together in a database,
right? And that's what they all do. And that's--in the end that's a rather complex and expensive
operation. So what RhoSync does that's a little bit unusual is, takes it from the backend
in a way that's usually a little bit closer to this object attribute value format because
it's reading it form some kind of serialized XML anyway. The sync method that we provide
but you can sort of change if you need to, then creates this object values right on the
server. When it goes--then it goes down to the device, we keep it in that object value
format. So we basically create a copy of this, sort of generic, you could call it property
bag schema, right? This generic property bag schema, this object values table then exist
on the device. So we don't have a whole bunch of relational tables, right? There's like
"the table". And the reason why we don't have to put it back together in the relational
tables is, in 2009, people expect to use an ORM. So it programmed to, right? They're not
expecting the right sequels statements. So when you write you're Rhodes app, you're using
RAM. I mean you can write sequel statements against that object value table, right? The
property bag schema if you want but it's not going to seem like, you know, your typical
thing of like selecting from your user's table and your location's table and your company's
table. It's all in one table and we get massive deficiencies by doing the sync to that one
table and yet it's still easy for the developer because they're just--they have an ORM that
mediates it. So that's maybe more than you wanted to know about why we did things the
way we did in RhoSync. Yes? >> So even though you're using a [INDISTINCT]
light, your [INDISTINCT] is working like a [INDISTINCT] of cache, okay?
>> BLUM: Yes. >> How was it different then when you [INDISTINCT]?
>> BLUM: It's--it's not really different at all. I mean, you could--it really does beg
the question is SQLite overkill? And it probably is, because it really is just a big table.
So we've been talking about that. Is there... >> [INDISTINCT]
>> BLUM: ...I believe SQLite is overkill for what we're doing there and will probably do
something more efficient there. This was--it was like the fastest path to get it out there,
right? But we absolutely do not need the power SQLite and on Blackberry we don't. What we
want to find is some real stripped down database that has far less and then rely on the RAM,
the ORM, to do most of the work for us. So on Blackberry we don't actually use SQLite,
we use FirstLite which is simpler. That's a whole other topic, like what's the right
backend given the simplicity of what we're really doing there? Such a good question.
So this is what you've seen. This is the process of generating Rhodes App. So upcoming developments.
We released 0.3 in early February. The big changes where we had GPS across all the platforms,
PIM access across the platforms. We added Symbian support. We actually added it for--there's
a bunch of--I meant--adjunct [INDISTINCT]. There's a bunch of PhD students doing Symbian
project so they want us to do Symbian ahead of Android. That's my excuse for not doing
Android before Symbian. You know if that washes but our 1.0 release will be released in about
a week and that has full Android. The Android stuff is all checked in. You can actually
build an App with it. It's just sort of a painful build process. So we have to add the
rig scripts for Android and then we can declare victory. It has devise capabilities. It has
camera support. It has SMS support and the other thing that's coming up and it will probably
be a couple of weeks after that is this product called RhoHub. So, you can think RhoHub as
basic--how many people have seen what Heroku does? So, what Heroku does is basically--it's
a hosted development site like you write your [INDISTINCT] app online. It's great stuff,
I'm a big fan of Heroku. We had a number of people that said, you know, I love Rhos but
I got to go set up a RhoSync server to do this and then I build the stuff and I have
all these versions that I need to make available to people and we're--we're going to make available
a provisioning server, open source to let-- help people with that. But okay, I've got
to have a Sync server and then I have to have a provisioning server and I have to have--I
have to set up these development environments, right, to do builts. And even if I use your
rake scripts I need to have something there but the rake scripts can call, right? The
iPhone Sdk has to be there. The Symbian Sdk has to at least be installed. So, what RhoHub
does it says you don't have to install anything. You don't have to install Sdks, you don't
have to install Sync server, you don't have to install a provisioning server, you just
get online you generate your App. We generate both sides for you, right? The Sync server
stuff and the client side stuff. And you only--for each object, you only describe the attributes
for that object one time, right? But it does both client and server. And you edit it online
right? You generate the HTML you edit the HTML online and then you just say built. So,
that is actually we're going to go to private data very soon. So anybody that's interested
if just register on RhoHub.com to get on the private beta, we're going to let the 100 people
in and as soon as our beta users tell us it's ready to go then we'll go live. So I'm guessing
that'll be something like the end of the month--I mean we're--it's--it's primarily a service
to just help accelerate people so we're not really in a huge hurry to put it out there.
It will be when users say--say it's ready. So, I guess my summary is why Rhodes and rhomobile,
we believe that the declared tag based approach to development has been shown sort of time
and time again, you know, the old web development paradigm of just writing HTML versus writing
to them, you know, procedural code is more productive. We think that the rich client--a
rich client that takes advantage of the device and works against Sync local data is a much
better experience than a mobile remote web App, luckily, that's not hard so much anymore.
We allow you to write it once and it works on all smartphones and it's open source from
the ground up. So with that, is it--makes sense to open the floor to questions?
>> [INDISTINCT] framework itself can be treated as a shared library on some or all the platforms
or is it always been [INDISTINCT] with the size of that. And I'm also curious if you--second
question--for the rendering HTML style sheets--are you taking a lot of the work that Apple did
to sort of promote buildings Apps to user browser and sort of using all those same kind
of style metaphors or is that infringing and they used to have you do something different
that's the same design. >> BLUM: So, what we've done is we actually
have tried to do the latter which is create a native like experience like Apple was promoting
for, you know, web Apps that take advantage of, you know, iPhone specific tags and we
started with the IEY to do that. And most of the stuff is IEY but we sort of gone further
than that and tried to do that against all platforms. And there's varying degrees of
ability to do that. I think if you see some of our full-fledged Apps like if you run the--you
can download our Sugar Serum App or you can just build it locally. I think we've achieved
that for iPhone. I think Blackberry and Windows mo--Blackberry and Windows mobile look pretty
good. We definitely have not gotten there for Symbian in terms of--I mean, the Symbian
apps look like web apps. I mean, there--it--they're local data, right? And they have native device
capability but they're pretty plain. We just don't have all that knowledge. We're actually
hoping our community is going to sort of contribute, you know, styling as they do their projects,
because we developers that want to do Symbian support. And just because we're new to Android,
you know, are probab--it's probably fair to say that our Android apps are also pretty
plain vanilla. So in--I'm sorry, can you repeat your first question?
>> Is the framework a shared library [INDISTINCT] on some of the iPhones [INDISTINCT] some component
[INDISTINCT]? >> BLUM: So, right now, I mean it's a--it's
a jam, right? So you do your jam, jam install and then that jam is available. But--oh, you
mean shared amongst all your apps, like DLL style or something?
>> Or if you install [INDISTINCT] apps, is anything shared?
>> BLUM: No. Nothing is shared. So this is actually a good question. We actually have
the capability of doing this and we thought a lot about--your point is well taken, we're
about--we're between two and three megs, so you could say, "Geez, on some devices, you
install multiple apps." You know, they all take two and three megs. In another words,
it's two and three megs after you've compiled anything. The good news is your app code's
real small, right? So your app code on top of our stuff is almost imperceptible. But
you're right, there's absolutely some duplication. We made a conscious decision to very much
focused on the--I just want to build my one-app scenario. There's certainly some inefficiencies
there. And to me, the idea that you want to make it more efficient by taking advantage
of the--all these things that you have and all the apps, right? They all have a web server,
they all have, you know, they all have the RhoSync client, they all have the browser
component. You know, isn't this duplication you want to make it more efficient. We will
do that eventually sort of driven by user demand, I mean, it's the right question to
ask but it also sort of deals like the problem of success, right? People love it so much,
they want to release a bunch of apps. We also want to very much stay away from--like, we
want Rhodes to be in the background, like it's your app, right? We don't want people
to know that there's Rhodes. So we very much stay away from the idea that Rhodes is this
like run time, right, that you get and then you download apps for that run time. That
certainly would be a way around this efficiency problem. But I don't think it--it doesn't--we
can do something more about shared libraries in the scenarios where people want to share
things, but we would only go as far as you've described, it's just the shared library. We
would not go as far as--well, here's this Rhodes run time and you can download apps.
>> [INDISTINCT] >> BLUM: So...
>> [INDISTINCT] >> BLUM: So for disclosure, we're only using
1.9 on everything but Java based devices. So we're using 1.9 for Symbian, we're 1.9
for iPhone, and we're using 1.9 for Windows Mobile. So Symbian, iPhone, Windows Mobile.
We--on Android and BlackBerry like JRuby did, JRuby is just too big. We already subset the
Ruby anyway, so that we fit. But JRuby was too big so we started with XRuby which is
sort of a dead ended project. But it was small enough to work with. And in the end, it's
sort or our Ruby now. If--maybe the second part of that question is, so are you guys
like the mobile Ruby Company? No, we're not the mobile Ruby Company, we're the framework
company. I--I'm a big fan of Ruby, I think there'll be native Rubies for all these devices,
and I'm more than happy if it doesn't come from us. So, today to answer your question,
we are 1.8 based, 1.86 sixth based for Java based platforms for both BlackBerry and Android,
and then 1.9 for everything else. And we're sort of hoping that--that either contributions
come from the community to take everything up to 1.9 or that mobile Ruby implementations
will emerge that we can just take advantage of. Yes.
>> [INDISTINCT]. >> BLUM: So, one of the things that--the question
was, are there apps in the apps store that are built on this? So, we have several developers
that we're working with, that we know are sort of about to release like imminently.
When I say imminently, like in the next week or two. So all the people I mentioned are
about to release. We don't know all the people that use our stuff. It's--github is even more
sort of anonymous than sourceForge, right? SourceForge today at least give you matrix,
right. You knew we're like watchers on github. And we know that we've gotten plenty of git
clones but we don't have any real view into that. So, there's so many apps in the apps
store, people may well have used our stuff and to do something simple and submit would
be very easy. We're--will be easy to do so there may be some. The ones that--the developers
that we've developed close relationships with, the--usually the reason why is they're doing
fairly ambitious large projects, right? Like mobile Wikipedia. And so they're just in that
whole testing cycle that you have with large projects and we're a new framework. So, the
answer is none that we're aware of, there will be several--like if I come back and talk
to you about Rhohub in a month or something, there'll be several out there by then.
>> [INDISTINCT] >> BLUM: No, so there's the rule 332 that
some of you are probably familiar with and with that, because somebody will say, well,
wait a minute, Ruby is an interpreter and you know you can't have an interpreter so,
it turns out there's many apps that clearly have an interpreter embedded. So the, like
the iPhone telnet client, there's a shell in it, right? So, there's clearly an interpreter
there. So, there's plenty of other interpreters in other apps. So, having a Ruby interpreter
per se is not violating but you're not allowed to do per rule 332 is download interpreted
code except with the exception of if you use a browser component, you're allowed to download
JavaScript. But in any other context, like you can't download JavaScript to some like
command line JavaScript or--or some kind of built in JavaScript. You can't load--you can't
download any code which then gets interpreted except with the exception of if, you know,
JavaScript downloaded to your browser component. So, what this means is, there's nothing wrong
with having the Ruby interpreter if you want to sort of be violating if you wrote code--it
would be a little tricky to do this within our framework but say you just said I don't
want to use your framework. I just want to use the Ruby. Somebody could--could deliberately
try to--try to write an infringing app by writing code that downloaded the Ruby and
then executed it with our interpreter. And that is possible. In order to not give people
some--you know, that much rope to hang themselves like we don't support eval. Like we took it
out really to protect people from doing things that would allow them to be infringing unknowingly.
But if somebody wants to be infringing, this is not going to stop them. There is ways to
get at the whole dynamic nature of Ruby. You know, beyond doing evals, there's other ways
of doing it. And so they can be infringing if they want to. But if they really want to
be infringing, there's a lot easier ways to do it than to use Rhodes or Ruby interpreter
for that matter. They can just get some shell interpreter which is like a hundred the size
to do it. Yeah. >> [INDISTINCT]
>> BLUM: See, it's--it's about three megs now. I was sort to hoping it would be around
two. And we think there's some things that we can do to get back down to two. It hasn't
been our focus for 1.0 so right around three megs with your app, you know, your app plus
it is about three megs. It's not actually a problem on any other devices like being
that big. It just feels a little too big. It's a bit bigger than we wanted it to be.
For some of the reason we talked about like, yeah, three megs is no big deal for one app
but you had enough three megs. Three megs here and three megs there and you're starting
to talk, you know, real, real, overly large footprints. So, there's some very specific
things that we can do like not having a full on database to store the object values table.
That would save us a lot of space. So, there's a--there is a lot of room for optimization
still. Even though, we're--you know, if you look at sort of our footprint of our Ruby
plus our framework versus like, you know, Ruby plus rails and a server, we're between
one and two orders of magnitude smaller but there's a--there's a fair amount of ways to
go. So, I would say that by, you know, say that you know, next several months so we could
get back down to two megs, but it hasn't--it just hasn't sort of hit the top of the priority
list. So, I can tell what we're all working on now is building a great Android implementation.
Yeah? >> So, [INDISTINCT] are you planning the ability
to escape into a native environment though to--I mean--also [INDISTINCT]?
>> BLUM: It's an interesting question. So, I mean, it's all because it's all open source.
You can--you can absolutely like feel free to mix in your own C libraries. One of the
big--one of the interesting specific scenarios is like would you want the ability to like
okay, get out from under your Ruby and like call some objective C library, right? We're
clearly doing it for specific device capabilities so, it's just I wanted to get to the GPS or
accelerometer and all these things. But there may be other context where you just say I
don't want to do this in Ruby. I want to do this in objective C and I still want to use
it from your app. So this is definitely possible to do and we do have--we even have a life
house tickets to have some documentation on the wiki on exactly how to do that because
I think that's a good thing to be able to do.
>> [INDISTINCT] >> BLUM: The other thing is in--that's is
going to actually fall out of--we going to have guides on the wiki for people that say
I, you know, I love the approach that I get device capabilities with HTML tags, but I'm
not willing to wait for you to provide that capability. So, for example, we had a developer
that asked us about proximity detection, you know, the whole controversial thing where
Google used that proximity detection APIs and in your awesome Search capability for
Google for the iPhone and so, I've talked to developers and said, I would really like
to have that, proximity detection API like in my Ruby code, right as a Ruby code. And
it's a very cool thing and we'll eventually do it. It's probably not going make the priority
list for like the three releases but we have developers that say I want to do it today.
So, we'll have some documentation on the wiki that says, "Okay, you want to create your
tag for something device specific. Here's how you go do it."
>> [INDISTINCT] >> BLUM: Well, accelerometer is very high
in the list, actually accelerometer will be 1.1. So, we're doing our 1.0 which--we're
in the finishing strokes of and then accelerometer is just very high in the list. And it's on
enough different devices that it makes sense to do. Proximity detection because it's not
really on a lot of devices, will be somewhat lower on the list.
>> So, [INDISTINCT] >> BLUM: You know, we're very much driven
by customer request. So, if we had somebody who's like actively developing an app and
they say I want barcodes scanning. We'll just do it. So, if you look at sort of our roadmap,
it really isn't--one of the reason--if people say, well, why is it 1.0, 1.0 is essentially
everything we sort of talked about doing, you know. Reasonably, we're a bust set of
device capabilities, you know, the basic write your app as HTML and it runs across all the
major platforms. So, 1.0 were sort of done like what the core of what our ideas are.
So now we're like a customer feature request machine. So file a light house issue and we'll
do it. >> [INDISTINCT]
>> BLUM: Absolutely. Yes and we're going to--that's what I'm saying is we're going to put documentation
on the wiki. We have all of our documentations up on the wiki now. We've even have customers
like edit it, you know, for us on the wiki like say we'll, I think, we need to add this
step. And we'll have documentation on the wiki that says here's how you go and add your
own capability to our set. Yeah? >> So this is going to be [INDISTINCT] question
for Android but you know, some Android [INDISTINCT] at least partially solve the question of [INDISTINCT]?
>> BLUM: So, if this is like a better way to access device capabilities, then probably
yes. We don't have any specific plans around that now. We probably just need to get--there's
no question were still learning about Android. So we should probably have a direct discussion
about it afterwards and we'd love to be educated by you guys on that. Yes.
>> [INDISTINCT] >> BLUM: Aha, that's an excellent question!
So, it really was always about--the question was can RhoSync run in online mode rather
than just offline mode. And I think, tell me if this is answering your question, so
RhoSync sort of makes the assumption that the server, the RhoSync server, connects to
your backend, grabs all the data it needs to, has it available for whenever that mobile
client chooses to connect, and then, you know, gets that data to the client. So, there's
a scenario where a client just wants to get--immediately get data from the backend and for which it
really doesn't make sense to be storing this object value triples on the server. It really
just wants data from the backend. And in fact the specific requestor of this was Wikipedia.
They said "We don't need to store this stuff in the meeting." So we like the meeting server
sort of doing the work to connect, so we call this the ask or the synchronous, it's basically
a synchronous query capability. And so there's another method that you can add. Remember
we talked about the six methods, you know, log-in, query, that's a query sync, there's
an ask method. So you can implement an ask method and then what happens is, if the controller
gets this ask request, right? You write it in your--in your app that it calls out to
the controller's ask request on that device, so then the controller does the ask request
out to the RhoSync server and then calls the source adaptor's ask method which then synchronously
queries the backend and then brings the data right back. And that's how actually Wikipedia's
implemented now and you can actually, not only can you go look at the Wikipedia app,
its up on github, but we actually take that source adaptor and we ship it with RhoSync
just because I like that example of the synchronous method.
>> [INDISTINCT] >> BLUM: So this is actually a good question.
So what your sort of saying is, is there a Rhodes that basically runs on a desktop or
a server? You can think of it as like a lightweight rails, right? is there a--is there a Rhodes
framework--no, there isn't today, it's definitely been requested, we'll probably do it soon
and it will probably, it's not so much because you really want to use Rhodes as your website
building thing, I'm a big fan of rails, RhoSync itself is a rails app, it's sort of--it almost
doesn't matter what's written in but it happens to be a rails app so if you're building a
server app, I'm not going to--theoretically--you could use Rhodes but I would say use rails,
it's a better framework for that kind of thing but you do want the ability--it would be nice
to be able to just sit on your device--on your laptop and run Rhodes on your laptop
without necessarily running emulators to test and so we will do that.
>> [INDISTINCT] >> BLUM: What you, What you're getting it
is and I think what you're getting is, is okay I'm writing on this Ruby code to write
my mobile device local thing. I want to be able share code with the--the mobile web version
and I think that's an interesting goal, the question would be and we're not focused on
this now but it's an intriguing thing, could you say, "Okay, I get the fact that Rhodes
is not what rails is," right, like a full thing to be like a web server environment
but maybe it could be just something for sort of serving mobile web clients, it's an intriguing
idea. I think it's a--it's an open question whether we would be really better than--than
rails at that--my gut is we probably wouldn't be but I think it's worth if--if somebody's
really going to try to do that, if you were really going to try to do that, we would probably
look at what could we do with sort of shared Ruby libraries to make that easier.
>> So, I think the--the real question now was I have--I have this view of my app and
I have viewed his app, in my browser, on the desktop [INDISTINCT].
>> BLUM: Yes, no, I get that so and I think that because models are just Ruby classes
like if you're using Rails, I think we, we--you can probably do that sort of ad hoc, right,
just have the same model but there may be things that we can do that make that even
easier, right? Like maybe have like you start apps in Rhodes and you want to have like your
Rails export or maybe it's the reverse, I've already written Rails app, I want sort of
a Rails sort of model import things. We don't have that today but I think it's a good suggestion.
>> Yes, [INDISTINCT]. >> BLUM: It's just the sample yes.
>> [INDISTINCT] boost for it. >> BLUM: It's--it's all of the objects, it's
quite robust. It's actually a--probably a little bit more extensive than some of the
apps that are out on the iPhone so yes, it's there and it's free for anybody to use, yes.
>> [INDISTINCT] my question is important so, is RhoHub code, open source into the point
where you can create your own implementation on an app engine, for example and use it,
use all the methods, everything that you network, we just re-implement it from scratch if you're
going to build the equivalent on [INDISTINCT]. >> BLUM: So, RhoHub today, we didn't--it's
actually up on github but it's private because we sort of didn't want to confuse users. Almost
all the key pieces like the provisioning server and the builds scripts sort of have their
own check ins like the build scripts are in the Rhodes check-in. The RhoSync server which
is a big piece of it is in RhoSync. There is this sort of web glue in between where
we sort of I think tie the Rhodes client and RhoSync server and the provisioning, we sort
of made that work flow a little easier to do and the question would be, do we take that
sort of thin web wrapper and open source that itself, I think we're open to doing that if
somebody really wants to build their own RhoHub but I think I'd want to sort of just hear
from somebody because I almost worry about just confusing developers. Like today our
message is if you want us to sort of host everything for you, just use RhoHub, if you
want to do it yourself, just, you know, get Rhodes and get RhoSync. If there was demand
and people wanted to build their own--we're really only really doing the hosted thing
not to try to make money with it like [INDISTINCT] or whatever, we're really just doing it as
a way to accelerate people success. So, if somebody else like app engine wanted to do
a RhoHub, we would be very encouraging of that scenario. Okay.
>> Is there any more questions? All right, well.
>> BLUM: Great, thank you. >> Thank you Adam for coming today.