Would like to write an ios app for my sailing club, is this doable?

[Blackjack200]

So, I sail with a club in Philadelphia and I'd like to develop an IOS app that will provide timely information to skippers and crew. Specifically I'd like to provide tide data (sourced from NOAA and available in text tables), and weather forecasts for the racing area (I believe I can pull this via FTP from the National Weather Service).

So this is how I imagine it working - the tide table is static and sits on a server (I'll host the server for development, when it goes live I'll probably have it hosted somewhere). The server pushes out an update to the IOS app every 6 hours with tide info for the next 24 hours. The server also pulls the weather forecast from NWS at whatever interval NWS updates its file, and pushes it out to the app.

That would be pretty much it to start with. Maybe later on other stuff could be added like reminders for club events etc.

I have limited coding experience but when I've done it I've generally picked it up pretty quickly. I'd be looking at this as a learning experience. Is this a good idea? Or am I just asking for a bunch of headaches and frustration?

My rough plan of attack is:

- Find the appropriate tide table - DONE. Tide Table is here: http://tidesandcurrents.noaa.gov/ge....3&ebbr=1.3&fldavgd=066&ebbavgd=248&footnote=

- Figure out how the NWS FTP pulls will work - Here's my starting point: http://www.nws.noaa.gov/tg/dataprod.php

- Learn IOS development and rough code app - Hit the library/bookstore and grab a book on Xcode??

- Test on home server - Really have no idea what's appropriate here. I imagine it will become clear as I learn the coding?

- Get it hosted

- Get it approved by Apple and into the app store (how hard is this?)

 

[Leros]

Everything you want sounds doable to me (I think iPhone apps can periodically wake up and pull data). The basically idea is simple but covers a lot of different technologies that you'll have to learn individually.

 

[black0ut]

Sounds completely possible.

1) If you've never done ios, you'll need to learn objc. To me it's just a more verbose c++ with slots/signals (dynamic binding) and decorators instead of RAII.

2) you'll need to learn xcode. i personally dislike using the layout builder in xcode because it creates xml which is impossible to merge in version control. i do all my gui programmatically.

3) As far as I know, you can't push content in ios other than popup notifications, or an application icon wiggle. That means that your app is actually pulling content off your server. That makes your server side trivial, just have some json endpoint that is updated with data every x hours.

4) Pretty straightforward until it's not. think of it like airport customs.

 

[slugg]

OP,

If I'm understanding what you want to do, your app doesn't need any kind of "push" data. Set up your web service to provide a datetime of last change. When the app loads or is refreshing its view of whatever information, poll the server for the last change. If the result is newer than the local cache, then download the new data. Else, just leave it. I don't see where "push" is necessary.

That being said, when you want to do sounds like it would be much more appropriate as a web app. You can make it look and feel pretty sweet with JQTouch UI. You don't have to worry about paying for a developer subscription, waiting for Apple to approve updates, or even getting rejected. Dealing with Apple really sucks, so if you can cut them out of the loop, that's always an advantage.

 

[Blackjack200]

Thanks for all the input. I hadn't thought of doing a web app, I'll definitely have to consider it. I spent a few hours going through the NWS website last night and checking out their FTP feeds. There's so much information to sort through.

 

[slugg]

Why FTP? Why not HTTP? If the latter, it would be nearly trivial.

 

[Leros]

I think it makes sense to have an app sync up periodically. When you're out sailing, you might not have internet access so it has to be locally cached.

 

[slugg]

I think it makes sense to have an app sync up periodically. When you're out sailing, you might not have internet access so it has to be locally cached.

Good point. But keep in mind that the only things iOS apps can do in the background is scheduled notifications, play audio, and VOiP. So unless the OP's app is running in the foreground, it will not sync/update.

edit: OP, it seems like you're just going to have to pick the lesser of evils here. Or maybe you can come up with something more sophisticated

 

[Leros]

Good point. But keep in mind that the only things iOS apps can do in the background is scheduled notifications, play audio, and VOiP. So unless the OP's app is running in the foreground, it will not sync/update.

edit: OP, it seems like you're just going to have to pick the lesser of evils here. Or maybe you can come up with something more sophisticated

I'm not sure that's true. I have a package tracking application that checks in with UPS/FedEx/etc and provides me with notifications as the status changes. It seems like it constantly runs since I get updates for several days after putting in the tracking number without having to open the application again.

 

[slugg]

I'm not sure that's true. I have a package tracking application that checks in with UPS/FedEx/etc and provides me with notifications as the status changes. It seems like it constantly runs since I get updates for several days after putting in the tracking number without having to open the application again.

Perception is reality. The phone itself is receiving push notifications (popups, sounds, text, etc), not the app. Then, when you open the app to check the notification, that's when the code runs to "sync" it. If you receive the notification, dismiss it, turn on airplane mode, then run the app, I'm willing to bet you won't see the new details. I hope I'm wrong, because then that means Apple is starting to lighten up!

 

[Blackjack200]

Wow, I obviously have a lot to learn about iOS.

As for the question about FTP, I just assumed that's how server side data pulls were done. I'll look into the HTTP option.

 

[black0ut]

OP,

If I'm understanding what you want to do, your app doesn't need any kind of "push" data. Set up your web service to provide a datetime of last change. When the app loads or is refreshing its view of whatever information, poll the server for the last change. If the result is newer than the local cache, then download the new data. Else, just leave it. I don't see where "push" is necessary.

That being said, when you want to do sounds like it would be much more appropriate as a web app. You can make it look and feel pretty sweet with JQTouch UI. You don't have to worry about paying for a developer subscription, waiting for Apple to approve updates, or even getting rejected. Dealing with Apple really sucks, so if you can cut them out of the loop, that's always an advantage.

Actually, now that you mention this, a WebView might be a way easier way of doing this. Especially for a newbie dev.

 

[Leros]

Perception is reality. The phone itself is receiving push notifications (popups, sounds, text, etc), not the app. Then, when you open the app to check the notification, that's when the code runs to "sync" it. If you receive the notification, dismiss it, turn on airplane mode, then run the app, I'm willing to bet you won't see the new details. I hope I'm wrong, because then that means Apple is starting to lighten up!

Hmm, you're probably right.

Since that's the case, I feel like the app should still keep a local cache of the data instead of just being a webview. If I'm on a boat where I don't have internet connection, it would be nice to have access to that data. Maybe I have to launch the app before leaving so I can download the latest data, but that's ok.

 

[slugg]

Hmm, you're probably right.

Since that's the case, I feel like the app should still keep a local cache of the data instead of just being a webview. If I'm on a boat where I don't have internet connection, it would be nice to have access to that data. Maybe I have to launch the app before leaving so I can download the latest data, but that's ok.

This.

 

[slpaulson]

Perception is reality. The phone itself is receiving push notifications (popups, sounds, text, etc), not the app. Then, when you open the app to check the notification, that's when the code runs to "sync" it. If you receive the notification, dismiss it, turn on airplane mode, then run the app, I'm willing to bet you won't see the new details. I hope I'm wrong, because then that means Apple is starting to lighten up!

Unfortunately you are correct. There's not a whole lot an iOS app can do when it's in the background.

If you have experience with the service side of things, I think you would probably probably want to write a service that you host, that would bring in whatever information that it is you want from the original sources, and serve it up to your iOS app in whatever format you want. I suggest having your web service bring together all the sources, instead of doing it in the app, because it would be a lot easier to update your service vs the app anytime the one of the sources you're using changes formats etc.

Your service could also send a push notification to your app if there's something urgent, such as a warning.

 

[mosco]

If you want to write a native app, this is a pretty simple app. If you want to use push notifications, and you are willing to pay, you can use something like Urban Airship if you don't want to roll your own.

In terms of writing a web app, you could easily write one that also used HTML5 local storage to provide offline caching and such. You would however lose out on push notifications.

You could also use something like PhoneGap to make HTML 5 "native app" but I would vote just a native app. You can use webviews on both platforms if you want to re-use some code across them.