It's been a long road to get this App published
21/05/11 18:24
Ever since Apple released its iPods and iPhones I’ve been trying to figure out how these devices could be incorporated into the everyday business flow of our POS Solution, Tracker and also if and how we could extend the usage of our File Handler DISAM.
We explored HTML based solutions early on and for quite a while actually, trying various Web-Kits. Some got close but nothing was a complete platform that we could rely on. Enhancements were slow in coming, probably because a lot of those early kits had a lone driver at the wheel and the vehicle being driven was simply his/her drive and desire to do something and share.
Of course Xcode was always available as an option but since our own expertise is kinda legacy, Xcode was not a very attractive option and since any development was truly the exploring kind budget was very important as there was and still is so very little of it to waste.
In case you’re wondering what I meant by legacy expertise, Standard C, some flavors of Basic and scripting associated with Unix, Linux, etc. Our Tracker solution started out on Radio Shack TRS-80’s and Model II’s and evolved via Oasis/Phase One Basic to Z-80 based machines and kept pace migrating to Linux, Windows and OS X. Efficiency is always our top priority, hence sticking with a text based core.
Just because we run a text-based core doesn’t mean we don’t want to make use of todays tools and devices, so its back to mobiles and how to connect those mobile devices to brick and mortar data.
The major shortcomings of the early solutions we tried had always been two-way communications. HTML would have given us most of the read capabilities we wanted but that wasn’t good enough. It has been our desire from the start to provide true and complete integration to the brick and mortar. Obviously we couldn’t replace a full blown work-station PC with a mobile device but we certainly could target specific tasks and spin those off to a mobile device.
It seemed that we were doomed to have Xcode be the only solution for us. To confirm that it was even doable in Xcode we enlisted outside freelance help to build a conceptual prototype. While that proved we were not totally off our rocker, it also proved that having an outsider develop an App would be more work than we wanted to take on, as we were still just exploring using a mobile device. I.e. learning our software would add quite a burden to a newcomer.
Back to the waiting game as we simply could not afford to divert resources to go exploring.
Every few months I would do another snoop around the Internet and eventually ran across the Ansca Corona SDK.
Being based on LUA it seemed somewhat familiar due to our use of UNIX shell scripting, however limited. I had never heard of Lua before but forged ahead and explored more. It wasn’t long before I plunked some money down to license the SDK. Initially, and still primarily targeting game developers, made for limited usage in a business environment. Even with those ‘good for gamers’ limitations I was able to produce an App for internal Ad Hoc distribution that enabled our customer to do on the spot inventory corrections. Gone were the days of writing it down for later processing at a workstation. Of course more times than not the paper never made it back to the work station.
We now had concept and usefulness confirmed but the SDK lacked the basic business capabilities that Xcode had available. Almost ready to throw in the towel I had myself resigned to having to learn Xcode. Even went so far as to head to the Book Store and come back with an armful. Uggghhh, I did not want to go there. All during this time Ansca kept hinting at some business related enhancements. I went so far as to write an email to Ansca sales/support asking/pleading for a hint of a timetable.
As is so often the case, after pressing send on the email I went back to the Ansca website and lo and behold there was a post describing availability of a Corona UI lua library. Being a subscriber I had immediate access and downloaded it. It came with sufficient examples and functionality that I was simply elated. A few long days and late nights later I had convinced myself that I had enough to work with. The Xcode books went on the shelf.
The obvious next step was to broaden usage to see if there was interest beyond our company. To do that we needed an App that would be accepted by Apple for distribution in the iTunes Store.
One of our customers, Rare Parts Inc., manufactures and distributes steering and suspension parts, not only to the Automotive Market but also to the Rebuilder, business and hobby.
It seemed like the ideal Test-Bed to further prove our ideas of integrating mobile solutions into our business solutions to be feasible. Ease of learning the Corona SDK is what made building the App possible with a minimum of resource diversion. We made some minor tweaks to our DISAM Server to facilitate efficient exchange of information and we had a few struggles wrapping our heads around the objective/dynamic programming of today, but we succeeded.
All Corona support was via the Corona Forum. We found the documentation and sample code snippets found on the Corona website to be quite helpful. Lua support was also readily available on the Internet and functionality was easily transposed from what we knew to what we had to learn.
The Corona SDK is getting better and better as time moves along. Still primarily for gamers but definitely making gains towards suitability for business.
The process of submission of the App to Apple was straight forward, to a large part due to information provided on the Corona website which references the pertinent Apple links to help one along the way.
End result was a Sunday upload with approval rand release to iTunes received on Thursday.
Thank you Ansca.
We explored HTML based solutions early on and for quite a while actually, trying various Web-Kits. Some got close but nothing was a complete platform that we could rely on. Enhancements were slow in coming, probably because a lot of those early kits had a lone driver at the wheel and the vehicle being driven was simply his/her drive and desire to do something and share.
Of course Xcode was always available as an option but since our own expertise is kinda legacy, Xcode was not a very attractive option and since any development was truly the exploring kind budget was very important as there was and still is so very little of it to waste.
In case you’re wondering what I meant by legacy expertise, Standard C, some flavors of Basic and scripting associated with Unix, Linux, etc. Our Tracker solution started out on Radio Shack TRS-80’s and Model II’s and evolved via Oasis/Phase One Basic to Z-80 based machines and kept pace migrating to Linux, Windows and OS X. Efficiency is always our top priority, hence sticking with a text based core.
Just because we run a text-based core doesn’t mean we don’t want to make use of todays tools and devices, so its back to mobiles and how to connect those mobile devices to brick and mortar data.
The major shortcomings of the early solutions we tried had always been two-way communications. HTML would have given us most of the read capabilities we wanted but that wasn’t good enough. It has been our desire from the start to provide true and complete integration to the brick and mortar. Obviously we couldn’t replace a full blown work-station PC with a mobile device but we certainly could target specific tasks and spin those off to a mobile device.
It seemed that we were doomed to have Xcode be the only solution for us. To confirm that it was even doable in Xcode we enlisted outside freelance help to build a conceptual prototype. While that proved we were not totally off our rocker, it also proved that having an outsider develop an App would be more work than we wanted to take on, as we were still just exploring using a mobile device. I.e. learning our software would add quite a burden to a newcomer.
Back to the waiting game as we simply could not afford to divert resources to go exploring.
Every few months I would do another snoop around the Internet and eventually ran across the Ansca Corona SDK.
Being based on LUA it seemed somewhat familiar due to our use of UNIX shell scripting, however limited. I had never heard of Lua before but forged ahead and explored more. It wasn’t long before I plunked some money down to license the SDK. Initially, and still primarily targeting game developers, made for limited usage in a business environment. Even with those ‘good for gamers’ limitations I was able to produce an App for internal Ad Hoc distribution that enabled our customer to do on the spot inventory corrections. Gone were the days of writing it down for later processing at a workstation. Of course more times than not the paper never made it back to the work station.
We now had concept and usefulness confirmed but the SDK lacked the basic business capabilities that Xcode had available. Almost ready to throw in the towel I had myself resigned to having to learn Xcode. Even went so far as to head to the Book Store and come back with an armful. Uggghhh, I did not want to go there. All during this time Ansca kept hinting at some business related enhancements. I went so far as to write an email to Ansca sales/support asking/pleading for a hint of a timetable.
As is so often the case, after pressing send on the email I went back to the Ansca website and lo and behold there was a post describing availability of a Corona UI lua library. Being a subscriber I had immediate access and downloaded it. It came with sufficient examples and functionality that I was simply elated. A few long days and late nights later I had convinced myself that I had enough to work with. The Xcode books went on the shelf.
The obvious next step was to broaden usage to see if there was interest beyond our company. To do that we needed an App that would be accepted by Apple for distribution in the iTunes Store.
One of our customers, Rare Parts Inc., manufactures and distributes steering and suspension parts, not only to the Automotive Market but also to the Rebuilder, business and hobby.
It seemed like the ideal Test-Bed to further prove our ideas of integrating mobile solutions into our business solutions to be feasible. Ease of learning the Corona SDK is what made building the App possible with a minimum of resource diversion. We made some minor tweaks to our DISAM Server to facilitate efficient exchange of information and we had a few struggles wrapping our heads around the objective/dynamic programming of today, but we succeeded.
All Corona support was via the Corona Forum. We found the documentation and sample code snippets found on the Corona website to be quite helpful. Lua support was also readily available on the Internet and functionality was easily transposed from what we knew to what we had to learn.
The Corona SDK is getting better and better as time moves along. Still primarily for gamers but definitely making gains towards suitability for business.
The process of submission of the App to Apple was straight forward, to a large part due to information provided on the Corona website which references the pertinent Apple links to help one along the way.
End result was a Sunday upload with approval rand release to iTunes received on Thursday.
Thank you Ansca.
The App has been accepted for Free distribution via the App Store
19/05/11 20:09
The App communicates with the Remote DISAM Server using standard Socket calls. Data is packed into XML tags to keep the byte traffic to a minimum.
Want more information? Drop us an email.
Attempting our first Official iOS App
16/05/11 16:31
Ever since the first iPhone was released we’ve been thinking about how to integrate DISAM into an Enterprise, making DISAM data available to Mobile devices.
We’ve now built our first App, utilizing the D7server and a custom RemoteIsam server to exchange information between mobile device and server using standard sockets and a somewhat modified XML structure. Basically the data exchange is in ASCII and you can build what’s needed.
Our target goals for the D7server is to provide a generic server that does the grunt-work based on simple ASCII command received via sockets.
Still a ways’ to go but making progress. App is at Apple awaiting review. Hopefully we’ll be able to tell you soon that it’s available for download.
We’ve now built our first App, utilizing the D7server and a custom RemoteIsam server to exchange information between mobile device and server using standard sockets and a somewhat modified XML structure. Basically the data exchange is in ASCII and you can build what’s needed.
Our target goals for the D7server is to provide a generic server that does the grunt-work based on simple ASCII command received via sockets.
Still a ways’ to go but making progress. App is at Apple awaiting review. Hopefully we’ll be able to tell you soon that it’s available for download.
What are we working on?
15/03/11 12:47
The next enhance under way is an ASCII Server for DISAM. Make your DISAM requests via sockets and some simple XML-type formatted text and the DISAM Server will return your data in an XML-type formatted response.
Note that we say XML-type text, we could also call it HTML-type. Basically we are taking the tag approach of XML/HTML with some formatting specific to the DISAM Server so as to minimize overhead.
You’ll be able to use any language that can do simple socket send/receive such as PHP, ASP, RealBasic, iOS, etc. so that you can access you DISAM data easily from websites, iPhone/iPad or any other platform/language that can do TCP/IP Sockets.
No target date yet, but if this is something of interest to you, drop us an email.
Note that we say XML-type text, we could also call it HTML-type. Basically we are taking the tag approach of XML/HTML with some formatting specific to the DISAM Server so as to minimize overhead.
You’ll be able to use any language that can do simple socket send/receive such as PHP, ASP, RealBasic, iOS, etc. so that you can access you DISAM data easily from websites, iPhone/iPad or any other platform/language that can do TCP/IP Sockets.
No target date yet, but if this is something of interest to you, drop us an email.
Some evals have been refreshed
31/12/09 18:34
Missed posting this a few days ago. Seems I’m just asleep at the switch these days. I’ll blame it on the Season.
Most DISAM evals have now been refreshed and the missing ones should be up tomorrow.
Most DISAM evals have now been refreshed and the missing ones should be up tomorrow.