Webapp, IOS app, desktop, or all of them?

We are evaluating the development of a software application help golfers improve their skills. We’ve looked at the apps that are currently offered and most of them track performance in the normal metrics that golfers see and hear - fairways hit, greens in regulation, number of putts, etc. And most of the mobile apps for golf provide course information and GPS data.

Our approach will be a little different and that’s what makes the decision on the type of app to create difficult.

Our application will have minimal data entry once the primary data is entered. The primary data will be the golfer’s name, email, and profile. The profile is calculated for them after they provide some basic information about their current abilities. We will probably preload the database with course data.

The data entry will consist of 4 or 5 values (or metrics) for each hole played. From this, we will calculate performance data that are compared to his current profile to evaluate his round of golf. The profile can be updated at any time by selecting rounds of golf that have been played as a measure of his abilities.

We are considering the following types of applications and each seems to have their own drawbacks. With the limited information that I have provided, I would like to hear what others might think about the following application platforms.

The desire to create this application comes from most of my staff being avid, although completely amateur, golfers. Consider it an act of appreciation for the game and a desire to help others improve and get more enjoyment from their time on the course. With that being said, other than the development time, we want to keep the fixed costs as low as possible. The pricing of the app will probably be ridiculously inexpensive.

Webapp - this would require a backend connected database such as XOJO Cloud and mean that we would update and maintain with the latest course information, etc. However, it would also mean that we would have to charge for monthly/annual access and manage subscriptions for accessing their data. It would also mean that we would have to put all the data in one database file and filter the user’s data.

My other concern is accessing the webapp on a phone (IOS or Android) and how easy it will be to obtain location information and present an interface that is suitable for a mobile device. For example, I know that on an iPhone they have different keyboards for different types of data entry. Is it possible in a webapp to display the numeric entry keyboard if that is all that is required versus the full alphabet keyboard if that is required?

IOS App - Can an IOS app be connected to a remote database? That’s just one of the questions I have. This would eliminate syncing data from the phone to a desktop application where reports could be printed and for more extensive data entry of course data, etc. If it can’t connect to a backend database, then the problem with syncing comes into play. Allowing the user to enter metrics during game play and then syncing to a desktop database at a later time.

I think one of the advantages of the IOS app is we should have access to all of the phone’s features, such as, camera, phone calling, and GPS.

If we connect to a remote database, we still have the problem of managing each user’s access and filtering their data.

Of course, the downside to an IOS app is only be able to sell it through the IOS App store. We already have some experience with this and quite honestly the biggest problem we have with it is that very often your app gets lost in the maze. We’d rather do our own marketing and distribution.

Desktop app - Since there are only 4 or 5 metrics that have to be entered for each hole played, the golfer could enter this information on his own personal scorecard and then enter the data later into a desktop app. All major data entry can be done in the desktop app and reports printed from it. It eliminates the need for a database sitting on a server and we would only have to activate the app for the user to have access to it. We currently do that with all of our desktop apps so this part of the process is ready to go.

We want to consider all approaches before continuing so if you have any thoughts on this, I would greatly appreciate your input. Right now, we have a blank slate to start with other than the feedback that we want to provide to the golfer.

I would think an iOS app (not that I am a fan of “Xojo for iOS”), but rather the app you have in mind.

Not knowing what “reports” need to be created… it is entirely feasible to have a on-device database, create PDF documents and send the via Airprint and/or email… without the need for a desktop computer. This way everything could be done in real time at the time the metrics were generated.

Again. not saying “Xojo for iOS” is the best way to create it, but an iOS app still might be your best solution…

Note: I have never played Golf in my life … so my point of view may be totally of base here.

A Web app can easily be configured so that only the number pad shows on a mobile phone when the user in on numeric fields. You just have to tell the IDE that this or that WebTextField is a Number field. At least that’s how it works on Android phones, I imagine it does that on iPhones as well. Very simple.

The current Webapps created with Xojo are too limited and outdated, Not really design to get along with multiple screen sizes (unles you create a different layout to each case like ios, Android, desktop, etc.) So, until Web 2.0 is released AND stable, better to consider other options.

ios is also limited, but, for your app maybe it is enought. If you dont care about Android support, you can use Xojo for iOS and a back end web service for database and user management.

Also, maybe consider a solution with Aloe Express For Xojo


I don’t see a property in a WebTextField that allows you to open a specific keyboard like the IOSTexField does. Can you be more specific?

In the IDE Inspector, you can easily set the Type of a WebTextField with a drop down menu in the Appearance section.

When you set the Type to Number, the browser will do something that causes the mobile phone to show the numeric keypad.

I don’t play golf, so take what I say with a grain of salt…

I would want an iOS app that works even without an Internet connection. So “syncing” should be seamless and behind the scenes. If the Internet is available, great, if not, use a local database until the Internet is available again and then sync. Since each golfer will presumably have his own records that no one else would be editing at the same time, syncing should be relatively painless.

At that point a web or desktop app could be used to review and print reports.

Yes, I’ve used a website’s API in one of my apps.

No worries… I deleted the private message, as it seemed you were not interested.

As mentioned previously, how to you cope with the difference screen sizes and making the controls “touch” friendly? I’ve created some mobile apps in Filemaker and they have a very easy way of handling this. They have themes, some of which include a theme for desktop and touch/mobile. You create your screens for the desktop using the desktop them and the one for touch/mobile using the mobile them. All the controls are specifically sized for touch when using the mobile them. It doesn’t matter if they are using the smallest iPhone or a tablet, it will provide a large control to make it easy to navigate and select.

There are a LOT of better tools for this task, most of them also much more cheaper than xojo, but remember the forum rules, you can’t mention competitive tools in here.

Well, Xojo is aware of whether or not the device is an iPhone, Android, etc. See this:


So you can, for instance, create one container for iPhone/Android sessions, and another for all the others. That’s what I do.

I don’t consider Filemaker a competitive tool. Their licensing is crazy expensive. I only mentioned it because they do have some innovative ways of dealing with different platforms.

[quote=417406:@Ralph Alvy]Well, Xojo is aware of whether or not the device is an iPhone, Android, etc. See this:


So you can, for instance, create one container for iPhone/Android sessions, and another for all the others. That’s what I do.[/quote]

You are gradually winning me over. Thank you for insightful replies.

No. You’ll have to communicate to the database via some sort of API via a HTTP Socket. I don’t have the name off the tip of my tongue but there are some readily available services that can make this relatively easy.