Creating Mobile App for Website

[clamum]

Hi guys. I'm going to be working on a new mobile application (Android, iOS, WinPhone using Xamarin) for the upcars.com website. I worked on the website years ago (it's been updated since, thankfully, lol) and know the owner very well.

When I last was working on the website, the data was in a MySQL database. I'm not sure if that's still the case or they moved to MSSQL. There's other possibilities but I'd say that's the most likely.

The mobile app will have the ability to show vehicle listings, just like the website, and allow the user to post a new vehicle listing (this is initial functionality).

I'm going to have a talk with the owner and web guy tomorrow, but I wanted to ask you guys something first. What would you use/create to expose the data and act as the mobile app's connection point?

My initial suggestion for this situation would be to create a web service that exposes the database, with methods like "GetVehicles(VehicleType, SearchFilters)" and "GetVehicle(VehicleID)" and so on. I'd probably end up having to create it, and would use Visual Studio/.NET to do so because I've done it in the past. I think that would work pretty well, but I'm not positive, so I ask you hax0rs what you'd do.

Thanks for any suggestions and insights!

 

[Broheim]

Web Api is my favorite tool for building webservices, followed by servicestack. I'd rather drag my manly bits through broken glass covered in diesel and aids than work with WCF.

the big issue in my eyes is going to be the search, since I imagine that you'd like to use facets, and facets on a RDBMS is a PITA if you have a lot of them.

 

[purbeast0]

i was using parse.com for an app i started last october, but in january they said they were no longer going to be hosting anymore but they open sourced parse-server. i've since moved it to my own heroku server and am running that instead. they have a great api and you can create your own cloud functions (written in javascript) that you can call from the clients very easily.

https://github.com/ParsePlatform

they have the parse-server on there and then also the sdk's for each mobile platform. not sure if you'd have interest since you said you're using xamarin (which i'd recommend against personally from experience) and it appears they have an sdk, but i have no experience with it.

https://components.xamarin.com/view/parse/

EDIT:

also, any reason you aren't just making a responsive website instead of apps? that would also fix the website.

 

[clamum]

Web Api is my favorite tool for building webservices, followed by servicestack. I'd rather drag my manly bits through broken glass covered in diesel and aids than work with WCF.

the big issue in my eyes is going to be the search, since I imagine that you'd like to use facets, and facets on a RDBMS is a PITA if you have a lot of them.

LOL. Yeah I haven't used WCF so I can't comment on it really. I haven't used Web API, either, though. The web services I've done were just the classic .wsdl type ones.

i was using parse.com for an app i started last october, but in january they said they were no longer going to be hosting anymore but they open sourced parse-server. i've since moved it to my own heroku server and am running that instead. they have a great api and you can create your own cloud functions (written in javascript) that you can call from the clients very easily.

https://github.com/ParsePlatform

they have the parse-server on there and then also the sdk's for each mobile platform. not sure if you'd have interest since you said you're using xamarin (which i'd recommend against personally from experience) and it appears they have an sdk, but i have no experience with it.

https://components.xamarin.com/view/parse/

EDIT:

also, any reason you aren't just making a responsive website instead of apps? that would also fix the website.

Hmmm. Parse looks pretty interesting. At least it gives me another option.

As for your question about a responsive website: the owner and the office manager are pretty set on a mobile app. I think their website should be responsive regardless (I haven't checked it out on a phone yet), but people in general are pretty app-obsessive I think. Also the app should be a much better way to post a listing than using the website, since it'll make use of the camera and whatnot.

 

[DaveSimmons]

You might not need an app for the camera:

<input type="file" accept="image/*;capture=camera">

See user3475960's answer here and the blog they link to: http://stackoverflow.com/questions/9431475/html5-camera-access

 

[purbeast0]

yeah you can definitely access the camera from websites. i've been looking at video chat API's recently and they all have a javascript version that accesses the camera.

 

[clamum]

Wow. Profanity redacted I did not know that.

Well I had a quick call with the guys yesterday. They definitely want an app; I didn't even propose a website overhaul cause they would've probably told me to profanity redacted . They've checked out apps from competitors and our proposed app would have features they lack and set the owner apart. Their website ain't horrible on a phone but maybe in the future I'll suggest it to him.

Anyway, I was given access to the website's Admin section and noticed that the database appears to be MS SQL and it's hosted in IIS, which has changed from what it was. But that should work well with the Web API service I'm thinking of doing.

Please avoid profanity and vulgarity in the tech forums -- Programming Moderator Ken g6

 

[purbeast0]

just a heads up, if you're using xamarin, i'd play around with the camera functionality on all devices you want to support before committing to it. i messed with phonegap a while ago and the camera usage on there was complete crap. ios you hardly had access to anything on it and the android one had more. it should be easy to get a quick camera app up and running to just be sure.

 

[clamum]

just a heads up, if you're using xamarin, i'd play around with the camera functionality on all devices you want to support before committing to it. i messed with phonegap a while ago and the camera usage on there was complete crap. ios you hardly had access to anything on it and the android one had more. it should be easy to get a quick camera app up and running to just be sure.

Hmmm. I suppose I could do that first before committing. Thanks for the heads up bro.

 

[clamum]

So I'm about to create a RESTful service for the website's database to provide a connection point for the mobile app.

What do you guys think I should do for authentication (I'm creating a Web API project using Visual Studio)? My first thought was to use "No Authentication" but then I thought maybe having a username and password would be better. The service will just have several "SELECT" type functions that get data from the database. I suppose in the near future it will have "INSERT" and "UPDATE" functions so I don't think I want any old person being able to do database inserts. I could code the username and password into the mobile app.

Hmmm. Maybe I just answered my own question. But I'd like some input if you guys would be so kind. Thanks.

 

[purbeast0]

if i was a user searching for cars to purchase and i had to create an account just to use the app and search for cars, i wouldn't use the app.

 

[DaveSimmons]

if i was a user searching for cars to purchase and i had to create an account just to use the app and search for cars, i wouldn't use the app.

Same here.

I don't want to give information to yet another site who will probably spam my mailbox, and might suffer a security breach and leak that information.

The app itself might also attempt to escalate its privileges through updates by exploiting some new-found security hole.

Even if nothing bad happens, why clutter my apps list for a site that I'll only visit a few times?

Given a choice between a web page for site A and an app for site B, I'll go to site A. "Apps for their own sake" do not appeal to me.

But: I am not your audience. Maybe they love apps as offering a better UI. Maybe they will visit your site frequently and app will work better for them. It's up to the business to know their market.

 

[clamum]

if i was a user searching for cars to purchase and i had to create an account just to use the app and search for cars, i wouldn't use the app.

Same here.

I don't want to give information to yet another site who will probably spam my mailbox, and might suffer a security breach and leak that information.

The app itself might also attempt to escalate its privileges through updates by exploiting some new-found security hole.

Even if nothing bad happens, why clutter my apps list for a site that I'll only visit a few times?

Given a choice between a web page for site A and an app for site B, I'll go to site A. "Apps for their own sake" do not appeal to me.

But: I am not your audience. Maybe they love apps as offering a better UI. Maybe they will visit your site frequently and app will work better for them. It's up to the business to know their market.

Thanks for the feedback guys. I really appreciate any comments or suggestions you have. There's a lot of really smart dudes here and I like to learn as much as I can.

As for the signing up in order to use the app, that will not be a requirement. The only people that will need to "login" with the app are car dealerships, and they must do that already on the current website.

When I mentioned the username and password, I was referring to authentication for the Web API service I'm creating. I figured I'd just put the credentials in the mobile app code. But I've heard that apps can be "decompiled" and the code looked at, to some degree. I don't know another way to hold credentials if I put basic authentication on the Web API service, though. It seems like I'd want authentication so any old person can't insert junk into the database, though they'd have to decompile the app I guess in order to get the URL for the Web API service. If I remember right, the website currently does have a "hold" that vehicles are placed into when they're first added and they need to be manually checked before they go up. Maybe that's sufficient and I won't need authentication?

I do kind of agree with you guys about the necessity of an app, though not completely. I guess I used to be much more of a website user if given the choice between app and website, though now I tend to use apps if I have a choice. I usually find they have better functionality but that's just a generalization. The business owner is definitely set on an app and I tend to trust that he knows his customers and business. I do think it could be something to set him apart, as long as I do my part and create something quality. Eeeek.

 

[Graze]

Whatever happened to a restfulful service and have it return some json?

 

[Ken g6]

True, just about every service I've made and/or used requires a POST login, and returns a token which must be sent back in the headers when using the RESTful service.

 

[DaveSimmons]

You might want to go to the Amazon AWS SDK and see how they handle security for clients. I've only skimmed it but I gather they have the client go to one service to get temporary authentication tokens to then use with the AWS API calls.

That way decompiling the app only gets you the URL for getting tokens, not a permanent set of credentials for your database service.

Also, for normal use this would be a "read-only" token / credentials. It makes sense to require a user name - password to obtain a (different) temporary token to allow sending data to the REST page for validation and then adding to the db.

Anonymous - only get the temporary low-security read-only token - only allowed to call service pages with certain validated searches.

Login - get a higher-security temporary token that allows calling other pages / functions for posting data to be validated and possibly added.

You'd probably want to log use by account, and possibly limit how fast / how many add requests it can make.

For both of these you would not accept raw SQL of course, and every field used would be heavily sanitized to catch little Bobby Tables.