Hello All
We have Lansa skills in house and an existing mobile app which we would like to re-write. Longrange appeals as it uses the same skill set.
Listed in most desireable order a Longrange app form must be able to do the follwing:
1. Offline capababilty: The Longrange app form can run in area where there is no network coverage or wifi access. The longrange form does not need to be requested from the server as it exists natively on the client.
2. Store and forward: The long range form can automatically detect when a the client is outside and inside network coverage and automatcially send the data to the server once it arrives in an area where network coverage is available.
3. Access to client local database: The long range form can access a local client database using standard SQL commands or RDML database commands (SELECT/FETCH/INSERT/DELETE).
4. Multithreading: The facility to run backgroun processes on seperate threads.
5. Access to client file system: The long range form can create/delete/read from/write to local client files
Are there any firm dates when any of the above features will be made available in LongReach ?
Jon
Longrange Features
-
Paul
Re: Longrange Features
Hi Jon,
I'd just like to comment on a couple of items on your requirements list that are already covered by LongRange.
3. Access to local database - In LongRange LANSA the main form views are RDMLX reusable parts and so have all the capablilites that LANSA components have. Database operations are programmed in the same way.
5. Access to client file system. LongRange has a snap in type called document views. These operate via LongReach. These can cuurently be used to access client file systems on IBM i.
I'd just like to comment on a couple of items on your requirements list that are already covered by LongRange.
3. Access to local database - In LongRange LANSA the main form views are RDMLX reusable parts and so have all the capablilites that LANSA components have. Database operations are programmed in the same way.
5. Access to client file system. LongRange has a snap in type called document views. These operate via LongReach. These can cuurently be used to access client file systems on IBM i.
Re: Longrange Features
This is interesting...
3. Access to local database - has anyone got any example code of Longrange connecting to an SQL database (sqllite?) on an ipad?
4. Access to client file system. I thought Jon was refering to the fle system on the ipad or iphone as the client rather than the iseries. Longrange asise if you can call an iseries host function you can do what you like with with the ifs usng 'ordinary' lansaa.
3. Access to local database - has anyone got any example code of Longrange connecting to an SQL database (sqllite?) on an ipad?
4. Access to client file system. I thought Jon was refering to the fle system on the ipad or iphone as the client rather than the iseries. Longrange asise if you can call an iseries host function you can do what you like with with the ifs usng 'ordinary' lansaa.
-
MarkDuignan
- Posts: 346
- Joined: Wed Apr 18, 2012 10:33 am
Re: Longrange Features
1. Offline capababilty: The Longrange app form can run in area where there is no network coverage or wifi access. The longrange form does not need to be requested from the server as it exists natively on the client.
You can do this now. See the shipped Programming Examples-> Web View Examples ->The /LongRange/Resource folder. This (rather ugly) little example demonstrates the most basic offline capability. You can do a lot more than this example suggest already. However – to do offline using only RPG or RDMLX skills you will need to wait until later in 4Q this year.
2. Store and forward: The long range form can automatically detect when a the client is outside and inside network coverage and automatically send the data to the server once it arrives in an area where network coverage is available.
That’s coming in 4Q - assuming you want to only code in RPG or RDMLX - otherwise you could probably do this right now. On iOS the App needs to have been started and running (ie: actually in view - in the foreground). My understanding is that an iOS App cannot be a long running background process. Once you hit the menu button on an App it gets a few seconds - and then it gets suspended/frozen and move to the background. It cannot consume CPU cycles again until the user (manually) wakes it up. There are special Apps that can do this (eg: mail) but in general this is how all iOS Apps work (suspended/frozen when not in view). I guess what I am saying is that this type of processing is a substantially more complex to design and implement than it may at first appear. See http://developer.apple.com/library/ios/ ... sFlow.html
3. Access to client local database: The long range form can access a local client database using standard SQL commands or RDML database commands (SELECT/FETCH/INSERT/DELETE).
That’s coming in 4Q (assuming you want to only code in RPG or RDMLX) - otherwise you can do this now. We plan to ship some improved documentation and examples of doing this within the next few weeks. I would also recommend having a look at the shipped Document View examples which relate to collecting from, distributing to and synchronizing the local file system and the server’s folder system. In planning in this area you need to consider that each individual App (iOS or Android) has its own private file system – and that there is no overarching file system that can work across them.
4. Multithreading: The facility to run background processes on seperate threads.
Yes – this is an intrinsic part of the 4Q offering’s design. No sure whether it actually needs threads yet – but it certainly needs to support concurrent asynchronous processing. Also strongly influenced by points in (2).
5. Access to client file system: The long range form can create/delete/read from/write to local client files
That’s coming in 4Q (assuming you want to only code in RPG or RDMLX) - otherwise you can do this now – hope to ship some ‘getting started’ doco and examples in the new few weeks.
You can do this now. See the shipped Programming Examples-> Web View Examples ->The /LongRange/Resource folder. This (rather ugly) little example demonstrates the most basic offline capability. You can do a lot more than this example suggest already. However – to do offline using only RPG or RDMLX skills you will need to wait until later in 4Q this year.
2. Store and forward: The long range form can automatically detect when a the client is outside and inside network coverage and automatically send the data to the server once it arrives in an area where network coverage is available.
That’s coming in 4Q - assuming you want to only code in RPG or RDMLX - otherwise you could probably do this right now. On iOS the App needs to have been started and running (ie: actually in view - in the foreground). My understanding is that an iOS App cannot be a long running background process. Once you hit the menu button on an App it gets a few seconds - and then it gets suspended/frozen and move to the background. It cannot consume CPU cycles again until the user (manually) wakes it up. There are special Apps that can do this (eg: mail) but in general this is how all iOS Apps work (suspended/frozen when not in view). I guess what I am saying is that this type of processing is a substantially more complex to design and implement than it may at first appear. See http://developer.apple.com/library/ios/ ... sFlow.html
3. Access to client local database: The long range form can access a local client database using standard SQL commands or RDML database commands (SELECT/FETCH/INSERT/DELETE).
That’s coming in 4Q (assuming you want to only code in RPG or RDMLX) - otherwise you can do this now. We plan to ship some improved documentation and examples of doing this within the next few weeks. I would also recommend having a look at the shipped Document View examples which relate to collecting from, distributing to and synchronizing the local file system and the server’s folder system. In planning in this area you need to consider that each individual App (iOS or Android) has its own private file system – and that there is no overarching file system that can work across them.
4. Multithreading: The facility to run background processes on seperate threads.
Yes – this is an intrinsic part of the 4Q offering’s design. No sure whether it actually needs threads yet – but it certainly needs to support concurrent asynchronous processing. Also strongly influenced by points in (2).
5. Access to client file system: The long range form can create/delete/read from/write to local client files
That’s coming in 4Q (assuming you want to only code in RPG or RDMLX) - otherwise you can do this now – hope to ship some ‘getting started’ doco and examples in the new few weeks.