 Well, good afternoon. This is the TaxiCap confession session. I'm going to be using this mic. Is there an echo in the back? Everybody can hear me, okay? Speak up. This a little bit better? Okay, great. Well, thank you for coming TaxiCap Confessions. This is a great slot. I guess Luke Verbilski got the hangover slot. This is the definitely not hungover anymore slot, right? Everybody's feeling good. Rested. Great. So it's a pretty simple case study presentation. What we did is we worked with a new startup Taxi Company that wanted a dispatch system that would work an iPad in their fleet and we build it with Drupal. So that's basically what I'm going to tell you about. So some of the things that I hope to convey through this case study is how Drupal was leveraged to do this application to build this application. Why we felt that it was the right choice to build this rapid app and hopefully I'll leave you with some ideas on how you can leverage Drupal in some of the ways And we have that we have done to build the application and maybe extend that and use other tools To build other systems. They'll do similar things I think there are a tremendous number of opportunities to replace proprietary hardware with software and I think Drupal is a as a great tool to do that on an enterprise level or not enterprise and Also to let you and your developers Leverage the skills that you already have to build some of these cool things So before I start going and talking about all this I guess I want to learn a little bit about yourselves. Who's Who here is a marketing decision-maker project manager? Cool. Okay developer All right Wow themeer Just okay. Cool. So fair warning. This is not a very technical presentation However, there are folks on on the team that have built this around So if you would like to stop by our booth Brandt when is actually running a buff right now. He's not here. So he would be able to answer some questions I have just roped in Johnny Fox. He's the project manager who will be able to help me answer some more technical questions So what I'll try to do since my my talk is not very Technical is I'll leave some time towards the end so you can go ahead and ask some of those questions and if you Want to leave right now? Hopefully not All right, so who am I my name is Andy Koharski as you can see I don't really take myself too seriously Take our work seriously. I this is me not being a firefighter not dressing up for Halloween. I'm actually Biking home from it's at night, and I'm it's cold and it's in Chicago, and I'm wearing a bike helmet So if you see that on my Some of the places online, that's me Normal dress attire in winter I'm the founder of Prometh Source. We're a sponsor booth for 17 and So a little bit more about the company That's some of the folks that are here with us In Denver, we are based in Chicago. We are a full-service technology firm We focus only on Drupal and mobile application development and providing Drupal managed services to sell things like 24-7 security updates And basically all the sexy support stuff that nobody wants to do about 40 team members and most of us are in Chicago as you'll see through this presentation and we do mobile application development both native and Hybrid and I'll talk a little bit about that and do we of course implement responsive design theme sites All right, so Taxi kept confessions About a year and a half ago Maybe a little bit longer We're approached by a group of Investors who are starting up and kicking off a new business. This is a concept of a green Taxi company in in Madison and now expanding into other areas of the country. It was The concept was to deliver It was a marketing concept and an approach to providing different rides the rides would be The service would offer a shared ride service to cut down on green gas footprint and also on a cost it would be equipped with a fleet of Priests and other Hybrid vehicles and they wanted to do some things differently than traditional taxi companies They wanted to differentiate themselves in the market So they came we've done some work with those folks before they They approached us and said well We really want to build a different dispatch system Well, we were buying a fleet of brand new Priests and what we really want to do is not only paint them a nice green color and do the things differently We want to use different technology We want to get away from having these clunky old boxes that sit inside of the cars And we want to have iPads in our Priests And we want our drivers to be able to pull information at any given time and provide That information to the passengers so Can you build a dispatch system that's going to provide us with a two-way communication can you Also, it has to be a zone-based calculation. So whenever somebody requests a ride We have to get the pickup location and the drop-off location because that's how we're going to calculate the ride We also want to track the Location of the cars. Oh, yeah, it has to be built in a month and a half because that's when the cars are getting rolling off And you know, they don't have a dispatch system. It's just gonna be sitting around losing lots and lots of money So of course we said yes We can do that At that point I was able to overrule some of the project some of the risk averse project managers Sometimes it works out for us And it just a little bit on a dispatch system For example, if I'm going to go back to The airport today, I can walk outside a convention center and flag a cab, right? That's just a normal way that you would do it in New York, Chicago, San Francisco most of the time outside of those cities what I would have to do is call and Provide my information to a dispatcher or an automated system provide an information about where I wanted to be picked up from and Where I'm going then that information would be stored. Maybe a fare would be calculated and Then at the time that I wanted to be picked up The taxi would be dispatched. So generally what happens is either a particular car or a group of cars in a particular area where I'm getting picked up from gets a message and Somebody accepts that message, right? So Five cars near the convention center five taxis near the convention center right around first one Information goes to all five. I'm the first one that accepts it that message gets sent back to the system So it's okay taxi number one two three four has their ride comes picks me up once I get in there It changes another status to get loaded. I mean that's actually a status loaded So that's that's how the dispatch system The the essential basic functionality of this back system As you can so I think I illustrated this definitely several points of information and information exchange between the mobile device and And the base system now. This is these are some images. I took Actually just from different different cities of the devices that currently exist Couple points on this This as you can see the this is it's because it's a hardware solution. It's extremely restricted on what it can do It's actually more expensive than putting I kept iPads in the car these things run around $2,000 from what I'm told And a little tangent on this there are a lot of different hardware solutions right now That are just like this. They're limited. They're very expensive. They're clunky They have a limited UI interface to have a limited upgrade ability. So it's as you're Looking at these devices and thinking about us. I would highly encourage you to think about Many different industries where this model can be replicated Okay, so we had a couple different options Option one was to go well Just refuse the work and the customer would go with the proprietary hardware solutions But I just showed you Option two was to build a custom code application. So this was something that we really considered very much considered so use something like a Framework maybe Ruby on rails or go with php coding nighter cake php Model out the database figure out, you know the traditional software development model Build the app that was definitely something we looked at or option three build the application using Drupal So we did it with Drupal We used Drupal as a dispatch center We obviously use the iPads as the mobile dispatch unit and we used phone gap for application development platform This is actually an image of what the insider Prius looks like with the mounted iPad in it Okay, so why Drupal? Why do we decided to do that? Well, one of the reasons was that we really thought we can pull this off We also are the best set of skills that we had in house where Drupal So even though it might have made a little just as much sense to use a completely custom framework We decided to use Drupal as a framework because we had felt comfortable with the fact that we had a set of skills in house that could accomplish that work and Drupal was giving us a lot out of the box already. So We felt that the fact that we can do the development cycle very quickly We had the services module in there. We had security build-in. We were able to provide immediate prototyping to the customer and As I said, this is important and for all the developers that are in here You already have the skills to basically build these applications There was no new skills that we had to go out and acquire. You can build the mobile app using services in Drupal We just did it with same skill set in house that we had while building other Drupal applications So on a mobile side, we have to consider whether we're going to go with native or hybrid and again I'm going to focus a little bit on the set and the fact that we had the skill set already there to implement this this build so Native or hybrid when I say native I mean building your iOS app or an Android app With the tools that they're put out either by Apple or by the Android community So building it for the specific device Hybrid is essentially building it with the skills that with the language that you're already familiar with so JavaScript HTML 5 And there are frameworks out there that provide you with the ability to build that app call native native functions on a device using JavaScript libraries or other I think there are other language packs now as well and then Package or compile that application to run on many different devices in our case the hardware that was the hardware of choice was the iPad So we went with phone gap Now phone gap since then has been acquired by Adobe, and I think it has been given back to the community It's part of the Apache project now but phone gap for the development on the On iPad gave us All this all the tools that we really needed to do so some of the disadvantages of using a hybrid approach Is that you don't have the ability to call all of the? Functions on the on the hardware that you're running so you know all the native calls to All the functionality that your iPhone iPad Android Device can do however we broke it down to be able to get geo location be able to get Direction and be able to get Actually, that's it. I think geo location was the main one So that was a pretty easy choice and again using phone gap gave us basically the tools Knowledge to build an application right out of the box because we already were doing similar things on the web Okay, so what do the app have to do so it had to save a ride request when I called in somebody was take somebody is taking a Call request that's saving it as a content type into Drupal. We're also we also look up Recurring ride requests of I'm a repeat customer. I can look they can look me up via a phone number And just pull that information up We had to be able to schedule a future ride request So the application can schedule to have me pick to have the taxi come and pick me up every Tuesday and take me to the airport and come and pick me up at the airport every you know Thursday night The other cool thing Depending on how you look at it Zone best zone based ride calculation. I'm gonna show you an image But essentially what it is is there are two ways to which in which you can calculate a ride cost One is when you sit down. There's a there's a meter that kicks off and as you drive There's a charge per mile and then probably a charge per time that you're in a car Another way of doing it is as calculating it from zone a to zone b some of that is dictated by municipalities. I know that we've looked at extending this application to Services that are not as as Regulated as a taxi industry So for example limo companies and they when we were able to apply the same zone fair calculations So like if you're going from you know, Brooklyn to Manhattan or something or a pro-west side lower east side or south side north side of Chicago We were to create zones and and for other applications be able to to create the cost calculations Of course the dispatch taxi So the signal has to be sent out to the taxi when that when that ride is ready to be picked up the drivers receive the application There's a little alert a little alarm. They either accept or decline that ride and during the ride May have because there's a joint ride that during the ride the taxi Dispatch system would have to be able to add more right requests to that driver And Driver would be able to decline or cancel the request and of course we have to display the location of the taxis So here's a here's a basic view Looking at Pulling up some ride information. So a dispatcher is able to see So the rows towards the top are rides that are in progress There are several statuses that And arose change the change color based on a status. So some of them are riders accepted but the passenger hasn't shown up or The ride is in progress or it's waiting outside and then the ones in the blue are waiting to be assigned We also are working on automatic automated assigned system. So there's no manual intervention Necessary but we can switch to different modes so here's an image of beautiful Madison, Wisconsin and Unfortunately, we chose orange to display the taxis So it doesn't show up very well here, but you can see the little donuts. Those are the taxis And you can you can hover over those get more information as to where they're going which direction they're going and the screen refreshes I think every 15 to 20 seconds to provide information Here's an example of a zone. So we used open layers and the zones were zone files where Okay, so here's a zone and it's basically a geo boundary and we and based on a location We get let long of where the taxi is or where to pick up location as then we figure out where they're going and based on that We have the the ability to calculate the cost, but there are something like 250 254 zones So here's the iPad app. I think the newer version is a little bit sexier So it's basically be able to accept a ride decline a ride. You can see the driver can see which zone the Pick up where which zone to pick up is in which zone It's going to now the application has the ability to map the route for the driver So just by automatically there's a link there where they can just say okay What's the fastest route for me to get there and there's some more functionality that we've added since this Screen so here's a here's a section of the dispatch room and some additional benefits of using this so Moving away from the traditional method And and just some benefits of using something like an iPad is that even though the We're only looking at the data plan for the devices They're using Skype to be able to communicate with the drivers if something that the system cannot handle or there's a Emergency or a problem happens so they've loaded other applications through the driver So like Skype and they communicate directly with the base using that. You know just using the data We're also providing. We also build in credit card processing using a little square We looked at using card IO, which was I don't know if you saw the key key note speech today to card IO you can basically put in a Card IO is an API that any application can use you use the camera and If you want to swipe a card you just you can use that to call Basically get the card information So you put the card in front of the camera card IO is a tool set that you can use They'll take a picture of that and almost instantaneously give you all the information that's on the card So it's an alternative to swiping it and then Additional benefits because we're using Drupal. We're able to have vehicle fleet management and driver management as well So it's just more and more benefits are rolling with that So a little bit on the architecture It's pretty pretty simple right you have Drupal running on top We have community contributed module community contributed modules open layers was a really big part of what we're doing with it with the driver maps and And the APIs are relying on getting that zone information Google Maps using that using Google Maps to get a lot of geo information where we're putting the addresses in on a dispatch system and Services we rely very very heavily on services to talk to the devices That there are some drawbacks. I'm gonna try to address them a couple more slides. So Notable modules open layers like I said services CCK views and date module. That's very important for us So I was very encouraged with the whiskey initiative When it was in the early stages hoping that we're not gonna have to bootstrap the entire Google Drupal load every time unfortunately it sounds like that's probably not gonna happen quite yet That's one of the challenges that we ran to while services module is fantastic. It allows for security So we build in the ability for the drivers to have to log in to the iPads and it's using their login to actually Control whether they are available for taking rides through the dispatch system And then we use another layer to make sure that that device actually has the ability to connect to our system It still boots the entire it still boots in does the entire boot. However Again going back and looking at our decision This was something that we're getting for free essentially with a Drupal install and a services install So that allowed us to prototype and build this app much faster than we had to build this thing from scratch from you know Using a framework so essentially we're kind of bending Drupal in a way To use it as a framework So some of the challenges that we had we actually hit the Google API limit Pretty much the day after we launched That was on an oversight where we're calling the We're calling the Testing testing was one of the challenges as well because we needed to figure out how to test with you know 3050 plus devices on a road Not only just to assimilate the loads but just to see you know if anything else anything funny was happening We weren't able to get those all those devices ready by then So the Google Maps API limit because we weren't able to test with all those devices We didn't realize that Did I say this is like a six-week development cycle, okay? So this is a six-week development cycle but we forgot to pull out a Google Maps API call in the devices and We are relying on the native geolocation call to the device But instead of we're using the Google API call that Google API call has a limit. There's nobody know off the top 2500 a day So that was a you know all of a sudden everything stopped working all the cars disappeared That was kind of bad, but we fixed it right away We did take this into consideration we wanted to limit the wireless traffic that was going back and forth So that you know when the iPads were purchased they were purchased on it with a with a service plan We didn't want to go over that that whatever the the bandwidth purchased was was so we did some testing on that Oh, I should also mention That with services we're using JSON. There was a there was a really a At first we looked at looking using XML But it was a very very quickly We just came to the conclusion that Jason is much much much easier and it's much easier because It's JavaScript that's predominantly used on Phone get app the native app. Sorry the hybrid app and also it works really well the Jason It works really well services in Drupal and unfortunately because every interaction with the iPad is an authenticated level and they communicate with the with the with the Drupal application Several times a minute or more than that after The database grew we started seeing some performance issues So that's still that's still a problem like I said, we would love to have to do this without boot bootstrapping in Drupal every time we make a call But we're going we're getting around that we are Rewriting some of the views and a dispatch center and we're doing calling the Geolocation updates a little bit smarter, but that was a consideration Another thing to mention is that I think there are more ways to do this now but when we when we're rolling this out there are three ways that we we We could roll out the code to the Apple device The first several we did with an iOS SDK so we literally Just hooked up the device to the developers Laptop and installed it there the app store is another option and we used an enterprise program where if we provided the app store the UID of the of the device they were able to basically over the air install the application So that's a very helpful model now the app store the Apple app store allows us to create subscription To sell this application as a subscription service So you can run it and install it as long as you pay a monthly recurring fee So let's build into the app store That's kind of cool if you're building enterprise applications like this so some next steps We are actually replacing the phone gap hybrid model with the native What a native build app? We're building the ability to SMS customers. We're working on we're talking about doing automatic driver routing It's done In that navigation that's also done We're also talking about Creating a metered functionality. So instead of doing the cost calculation that goes between from zone to zone essentially You know like if you use the you know who uses like map my run So you take your iPhone and you run with it for however long and you stop and you look back and it traces your your route so basically the same principle to create the To create that basically to figure out what the distance is the taxi was traveling and figure out the cost of the ride based on number of miles traveled and We're doing a lot of reporting and Driver management that type of stuff with Drupal And finally Has this launched yet? It's any minute now any day any day so we built a And there's several of these out there already, but we've built this Particularly for for this company Who's expanding into other cities in the US? And this also interact interacts with Drupal. It's a native application that essentially lets you so if I'm If these guys had a service in Denver, I would be able to pull out my app my phone Load the application and say I am in this location and I need a taxi right now It would create a call to the dispatch or it's actually gonna first it's gonna figure out to let me figure out the exact address Or for I am Request that ride once that right request happens that gets saved to Drupal It goes into our Dispatch application and then the one what I think is a pretty cool thing is that we're allowing The user to track the taxi right because as soon as the driver Accepts the ride we can track where they are so I can track where my my when my car is coming So I'm wrapping up. I think this is Actually a little bit early but in conclusion I wanted to I hope I have Illustrated through this case study that we made a decision to use Drupal as a framework to connect Many distributed mobile devices and we're able to pull that off in a very very short time frame This is a six-week development cycle. We're able to use all the skills that we Had in-house so at that point we didn't have any iPhone iOS developers All we knew was PHP JavaScript Drupal Drupal and Just worked very hard and obviously we have to thank the community For providing these services to be able to do that Right away, so we're looking forward to seeing what's going to happen with whiskey or to form or initiative formally known as whiskey So we can do some of these things faster, but it's possible out of the box right now with the skill set that everybody has so With that, I'll be happy to take some questions Can you talk to I kind of two questions are a little bit related one Did you guys happen to look at titanium accelerator while you were considering the hybrid app? And so if you would mind talking about the decision point between phone gap and titanium if there was one And also you said you're going native after having done a hybrid What are the what are the pain points that are or why are you going native after having done hybrid? Okay, so Johnny will you help me out with some of these questions? All right, so this was developed Like a year and a half ago, so titanium was not as mature at the time We wanted to do something very quickly. So Phone gap really is a web page just written and wrapped inside of a native wrapper So, you know, we had a high degree of confidence that with phone gap we could deliver and meet our deadline And so that was really the choice of doing that It's kind of the challenge with phone gap and I think it's a more mature platform now But at the time phone gap loads your entire application into one page So on the device it's possible to run out of memory when we start loading a lot of JavaScript operations running now we've added mapping into the into the phone gap app and Occasionally the browser will just crash because you are actually using Just a browser basically so With adding mapping credit card processing Some of the other things native is just quicker and also just you know as a web page or you're polling so The Ability to use Apple push notifications as native. It's just it's a little bit better that way All right I'm guessing a lot of this is at least with the Phone gap in implementation is Pulling as opposed to pushing out to the clients and then also can you talk a little bit about your data architecture? Sort of how you structured Relationships and all that between how you built out nodes maybe on this The node architecture I can't speak to as much where some of that is being re-architected You know it was it was done very quickly and if you think about just the size of the project, you know six weeks That's kind of word go design architecture So performance has been some of the things we've come back and re-engineered so that it pulls slower As I was mentioning we're rewriting it so that we're going to have push notifications to push to To the device Probably going to use some node JS also to use make use of web sockets And produce that load on the server Yeah, I was wondering I've been a mobile developer for the last three years and I've never really used phone gap or any of those Things I was wondering how easy it is to follow the UI guidelines for the different devices when you're using phone gap It's fine. There's you know Thousands of apps that use phone gap. You just have to kind of follow a lot of the The guidelines well If you're using enterprise distribution for one thing you do not have to comply with the data Guidelines well If you're using enterprise distribution for one thing you do not have to comply with those guidelines is we actually have where a Private distribution where they're able to side load the device into there So we're able to do whatever we need to for a proprietary application like that The consumer app does have to pass the UI guidelines and it is in native So, you know, it's like any other app that at that point Thanks Two questions really the first one being what other use cases do you see for an application like this? either in, you know, this type of cab or service industry with vehicles or You know transportation of sorts and the other one being how much of this can be contributed back to the community So we can build other apps like this with this model. Great question Eric two questions. So I Dream of and think of use cases all the time for this so And we've been talking to other limo tech limo companies that want to use this So obviously we can extend that to the transportation industry. It's very specifically around, you know, taxi limo type industry There are to there are many many many more use cases if you extend this application a little bit further for example servicing application. So if I am a Snowplow and we have a big big snow in Chicago, I can load up all the places that I have to plow As a private plower and and go to and just check them off as I go along I can then this application can maybe they even help me organize Which is what's my efficient most efficient route or as a, you know pool cleaner, right? same thing load up your workflow or if you you know if you're Delivery driver and all of a sudden you have to you know You can carry a little bit more inventory on your truck and if you have a new order that comes in You can dispatch to that driver where to go and what to load off using a similar application. I mean Trans Yeah, I've been sitting around a pool and a vacation and we're speaking to a landscape business owner who said I need this Type of an application exactly like this so I can sometimes my routes to my folks change and I want to be able to do that second question You know how to contribute this back to the community. I mean, you know, we're basically You know all the stuff that we use is Aside from your phone get a go phone gap app, it's it's pretty much Pure Drupal out of the box contributed modules open layers all of that stuff Is out there? We haven't had discussion around contributing the phone gap app back, but that's a really good That's a really good point. So there's no real custom code that could be contributed back as a module or an install profile No, I mean it's it's it's one web page The the phone gap app is really just one page. I mean, it's it's a very simple page Of doing that and it's it's just calling services with a JSON call and when it gets those back It you know populates those divs on the screen, you know, you have your buttons Very simple stuff You know what I'll do is I'll try to rearchitect this to be a little bit more technical talk and at the next CD mug So we're both from Chicago, but I'll try to give And and I will post this up. This is we'll post this up and we'll try to post some of the code up You know, it's probably a little ugly because it's been This is developing six. It's been cleaned up. Okay, so yes, we'd be happy to go ahead I have a question. What kind of subscription model are you using for this app distribution? Yeah, so this for this particular customer. It's it's an enterprise level distro. So it's basically they just have it Right, they just give us UIDs and they have it we have talked about And I'm not gonna remember the terminology there's a subscription model on the app store That you can have enterprises purchase this now as a business model, you know They also need the dispatch center that's gonna be configured to speak to a set of devices So, you know, we're working on that right now because they're they're opening up in a different city. So It's gonna, you know To extend it to thousands and thousands of different businesses What you have to do is install the base the dispatch system and then attach the devices to that system So it's a two-point install the base and then on device install So one of the things that we talked about is doing having a price for the base install And then having a recurring a pretty low base price install and having a recurring revenue model That would be purchased through the iStore iPhone app store On every end pay for a recurring monthly basis something like five or 15 bucks So is it gonna be like in app purchase or there is another recurring like I'm just concerned like is there a model that Exists for recurring billing for apps yet. Is there a model exists for recurring billing of apps? Yeah Yeah, the app store has a recurring billing model for apps on enterprise level. It's that it's there You can put your app out there and charge recurring billing for it. Thanks. Thanks So I have a couple of questions one is of the 40 plus how many how many of your staff were on this project and then How much were you able to actually develop in parallel and can you kind of describe like some of the the maybe pieces that Ended up being bottlenecks because they took a lot more effort than than you originally anticipated Yeah, great question. So we had Actually, it was a pretty lean staff. We had two senior developers a project manager a business analyst and a QA person working on this at one point we had Maybe a theme or help out but very insignificant So it was a very lean project And we wanted to do that so that you know, we didn't have too many people tripping over each other And when we broke it down, we obviously the timeline was more one or more important one of the most one of the very important considerations, so You know, we pretty much had free reign at any resources that needed to be on it And when we broke down to work and we looked at the backlog and and what needed to be done and we Kind of decided once the piece was architected that it really could be two people so From what I remember some of the some of the problems that we had where Updating the location of the of the cars I Took us a little while to figure out And it's just because I mean it's easy, you know now we now that we know what we're doing It's easy, but when we were first looking at it. That was that was slightly difficult I Think what ended up happening is we We had a very good Coincidence where the cars were late The cars were delivered a little bit late So we had like one more week to test which we worked out most of the kinks. So that was very helpful Did I answer all your questions Johnny? Do you have a comment on that? difficulties that we ran into The performance performance was an issue, but not right right away No, just testing through all the the use cases normal, you know kind of problems with testing when you have One system that talks to each other just as we've been going through ongoing development, you know, that's We had some issues with Testing what's going on inside of the web page, but IOS The new SDK Actually allows you to use Safari's inspector for inspecting what's going on inside of the phone gap app Really expedites troubleshooting. Otherwise, you have to put in Json our JavaScript alert boxes to see what's going on inside the phone gap Hey guys, great case study. Thank you I'm just curious you mentioned that you used open layers and the Google Maps API So can you talk about kind of the division what? What features of each that you've used? Yeah, I mean we used So Johnny you can back me up. All right Open layers is used on the dispatch Screen to map the ride that where the taxis are and it was used to layer the zones Maps API was to take the address input and get a lot long Sorry Yeah, so so basically clean use that to clean out the input clean up the input Provide, you know, if it's a guess that Google map Google Maps API brings back Yeah, so let's tell those are used. So then are you using any caching for the maps on the iPad side of things I'm just curious about like how much data Like, you know, I imagine these iPads are on all day every day So how much data are they are they actually using? From a data plan. Yeah, they're they're close. They're about I think 60 70% They're not going over like the basic basic plan or whatever that is Yeah, so that sounds like the maps are being cached then There's the maps are the maps are not called every time they they go the The Location is actually sent from For mapping is sent to the dispatch board So it depends on how often they're seeing it on there from the device location The only time that they'll call for Google Maps is if if he's needing to be routed to a location He's not familiar with so from from the iPad device. It's just absolutely submitting the raw Yeah, exactly. Yeah, what I had is a consumer app Which might have been a little bit misleading because I was bringing up the map the maps are actually on a dispatch Application which is a Drupal app sitting at the desktop now They're able to link the pickup and a drop-off location and pull up just a Google map in a web page Which yes, it does consume Bandwidth but these these calls are you know, they don't make and the apps that the Google the iPads Don't make a call to Google Maps for location They use the the native call to get the current that long and then they do send that back to dispatch But it's a small call So So I guess I was assuming that the apps you guys created actually will help navigate the driver To the pickup, but you're using like the standard Maps application Yeah, that's it. So Do we use any do we build our own navigation? No, we didn't the what we're are working now right now Which is kind of cool is to be able or I guess it's already done to be able to automatically assign the driver To the pickup location So that's you know a little bit of intelligence built-in based on location of the driver pickup part part of the reason for going to a Native app is right now. We're calling the own device map kit if you're familiar with iOS Is we're just calling it as an external application? So in the native version, we'll be just embedding that as a as a native control It's just a little bit more natural that way Um, maybe I didn't catch it, but how did you overcome this? Bootstrapping problem, that's a great question. We haven't Do you have plans just to move everything to two different solution like out of the Drupal? We actually don't You know, we're right now figuring out how you know, how many cabs can run on this thing Believe it or not what we would do is We'd probably eliminate views and write around queries that would be the first thing so that you know We had I mean distinct generates. It's actually amazing how many ride requests are generated by this small taxi company It's you know hundreds and hundreds of thousands of rides requests in there. It's about a thousand rides a weekend Thousand rides a weekend so So sorry so on a performance side yeah, the The communication with from the from the cars obviously we were figuring out how many we would like to be able to ride You know have 500 iPads and a single installation without any problems Some of the problems that we the first problems with performance that we have seen is actually from the view because nothing can be cached Right, there's no caching Almost done. It's it's even on a database on a database layer. It's like every The caching stays in there for just a couple of seconds because there's there's an update almost all at all time and every User is it as an authenticated user in our Drupal instance? So this is the biggest this was the first and the biggest pain for us So so we may be actually rewriting this and not using views So we have to give up a little bit of the of the of the ease of views But you know, we're gonna gain some performance. I mean we looked at the queries in there and we modified them, but They're kind of ugly Well, the problem with bootstrapping is you're you're loading up the entire Drupal stack in order to process one request as opposed to just going in that one thing that you need to do so You know as each one of these Cabs is out in the field and it's making a post to Drupal. It's it basically loads up the whole stack to do that so I Don't know we haven't we haven't addressed that problem yet. We've basically been able to overcome it for performance problems by my sequel tuning by restricting some of how many rows are requested in the view and Extending the time between poles Yeah, I mean, that's the classic problem that I think Dries was talking about in his keynote, right and and Larry spoke to and It's one of the initiatives for eight and again, unfortunately. It looks like bootstrapping is not gonna be part of Initiative formally known as whiskey as the talk that he gave earlier And that is you know when you're just looking for a Jason object to get out of Drupal You don't want the whole page load, right? You just I just want to be able to say authenticate and just give me that object You know and Drupal tries to check for things like are there blocks on this page are there? Views that what else do I have to execute all the things that are happening? So I think you know we like to think of Drupal and there was a question earlier and that is you know What other what where what are what are the other you case use? use cases That you can that we think of when we try to you know, we're looking at this app We think that Drupal could be used as a as a data warehouse of data and information and be used Extended for many many many many uses. I mean, there's like me. Yeah, there's something new I learned about Every day about how you people are using Drupal and especially that way and we prop and we we promote that used to our clients and We're hoping to and I think somebody's gonna solve it We're probably have to look at solving it ourselves or at least contributing into that direction That is I want to be able to use Drupal to pull information and I mean all of you guys are gonna be able to be doing that in a couple of years Anyway, right? I mean who? You know and may not be an html HTTP response html response that you're looking for pulled data out of Drupal or put data into Drupal, right? I mean Unknown how many how the devices are gonna be interacting with the with Drupal But even though although it has these limitations and look it's a little bit slow because it loads of the whole thing It is still easier for us in my opinion to house Data into Drupal and to migrate into Drupal because you get all these all these things for free and then build an app Around that to pull information out whether it's in real time or whether it gets updated and it gets stored local or You know you can use Drupal to build your mobile apps and extend it. I mean, you know, we're building apps that have for example Instructions for our tractor Spraying systems and 16 different languages. Well if something changes what we did is we could just reach back into Drupal and pull that information Out so we check for updates that way. I think I answered that question, right? Hey, I just wanted to join into the bootstrap Conversation though the problem is actually that services runs a full bootstrap every time so views especially heavy then but There I actually want to build services 4.0 at least without a bootstrap So that's pretty probably a good point for you guys to join in there in the development of services Maybe and then get a better product for yourself and then also get a better product for the community out of there So that's one of the things on the list and then second thing maybe I came in a little late So do you use push notification at all or do you pull everything? One of the recent updates is we are Moving to push notifications. There's a mixture right now because there's some legacy Pieces that need rewritten, but we'll eventually be going to all push notifications No, because we have some application use push notification and that solves a lot of the issues there Right, right Yeah, thanks for that heads up. That's and that's great and the third thing quickly here I don't know if you guys use it or look into it because you go back to native Something we just started doing is like flash builder. So there's a lot of old action script develop out there probably which are like Work and have no work at these days anymore because everything is web 2.0 So if you go flash build also the next generation of flags You can build pretty much an action script 3 applications which are cross-platform and you can use the services via a MF PHP server instead of Jason so you natively talk to flash those applications are then built natively in Android and in Objective C basically so they're they're really native native. So full-performance It's a very interesting approach if you want to look into that We have two projects out there right now and Yeah, it's very performing it works pretty well That's cool. That's good info and thanks for that services. That's that's key like I want so I just want to make sure everybody here except there's a lot of developers here, so Services module is now working on actually bypassing the bootstrap problem So if anybody wants to help contribute we'll definitely try to look into that that that's a worthy cause for mobile do you use Google traffic at all or do you have some way of Kind of collecting from your drivers like don't go down 2nd Avenue because they spilled a bunch of beer Well, I know I use Google traffic a lot, but no we That's personally we have not built that into app. That's a that's a really good point I mean, you know when it's it's a it's a question of a budget and maybe in further iterations We do that because when our driver routes that writes their ride We don't take into consideration traffic now. We are relying on Google to do that So me because we're just pushing them basically out to Google Maps So if they you know, they might have a little more resources. I don't know if they're figuring that out yet All right. Thank you very much