We use a back-office accounting system with an SQL db2 database. Our sales, service and management all have Blackberries. I have started to write some HTML web scripts that go through BES sever so staff can access and update data (sales summaries, late orders, AR approvals).
The next level seems to be using the native blackberry applets to manage data. For instance we could use an application that notifies head of A/R when a substancial order is being prepared for a customer who is behind in payments. This would require a form of push notification (message and/or email) from server, an entry in Blackberry database, a screen to view list of unapproved orders, a way to approve/reject orders that would update local database and backoffice server.
Questions
what language? Java J2ME with blackberry classes seem most obvious, but is there any viable rapid development tools on this platform?
what database on Blackberry? Is there a choice?
what is appropriate technology to push and pull data (sockets, http?)
can we hire a regular Java guy with a year or two exp, or do we need a Blackberry specialist
is synchronizing data an issue. If blackberry is out of range, will missing messages be synchronized automatically or do you have to control this programically?
thank you
Blackberry apps are Java using a proprietary API. It's derived from J2ME but you have to use the BB APIs in order to do anything interesting. A lot of BB developers use the Eclipse plugin. Compared to Android and iPhone BB dev is a bit clunky.
BB's running OS 5 and higher have SQLite on the device. All devices have a "Persistent Store". The store gives you broad support if your users have older devices.
Now of course on your backend you can use whatever database you want :)
BB's can do http, sockets, wifi (depending on the device). Things like carrier-tcp can be unreliable on older devices and with certain carriers. However since you have a BES, you can use the MDS service which tends to be reliable (provided the BES is running).
You can also get notified from push messages which are sent to the BES. This is useful for low-latency.
I guess most people can learn this, but I recommend finding someone with specific BB knowledge. In my experience I've found the platform pretty tricky to do things well. I've had to experiment a lot to get things working.
Push messages are 'fire and forgot' but there is a 'reliable push' mechanism I haven't used. In general wireless apps have to be good about not depending on network reliability.
Related
I'm considering switching from Firebase DB to Realm.io for my Android app.
From what I've read - https://realm.io/docs/java/latest/#getting-started :
We do not support Java outside of Android at the moment.
That seems like an odd limitation for such a (supposedly) mature library.
I'm thinking that this could complicate e.g. automatic testing, requiring tests to be run on device/emulator, slowing things down a lot.
Questions:
Is it really the case that it cannot be used outside of Android?
What is the reason of this limitation?
Is it really as bad as I think?
What if I want to have some auxiliary server app (written in Java) running somewhere in the cloud, e.g. AppEngine, to connect to the realm DB. Is that option excluded?
What workarounds are there, e.g. for testing and server-side Java?
For the latter purpose - is NodeJS server-side app supported?
That seems like an odd limitation for such a (supposedly) mature library.
It's not that odd a limitation if you consider the fact that Realm ships its own native core, and the JNI wrapper written for the Android NDK; and it hasn't been detached from it yet to make it platform-agnostic, and as such for example relies on Android-specific things in certain places - for example, notifications, using the "Looper" as its specific event loop implementation.
Technically, the realm-java binding has plans to support Java outside of Android, but it currently does not. You should think of it more-so as realm-android than realm-java at this time.
Realm-Core at the time did not support UWP and Windows yet, although now realm-dotnet project works for Windows as well. Even so, detaching Realm-Java's implementation from Android is difficult.
I'm thinking that this could complicate e.g. automatic testing, requiring tests to be run on device/emulator, slowing things down a lot.
For testing Realm-specific behavior, yes.
For testing other things in your app with unit tests, no. You just need the right design, and some mocks I guess.
Is it really the case that it cannot be used outside of Android?
It works on iOS and Android as a local database.
It also works on Linux as a local server-side database since this article from Nov 16 2016, using a similar (the same?) API to the React-Native Realm API, via NodeJS.
You can also run a Realm Object Server (ROS) free of charge on whatever Linux or MacOS machine you like.
Then you can use the sync API to connect to said ROS, and automatically synchronize Realm associated with a user to the ROS. That's what you can do with ROS for free.
With the Enterprise Professional Edition and its price, you can also (on the server side) read/write to Sync Realms, and listen to events that alter the Sync Realm via the NodeJS Realm API.
Is it really as bad as I think?
That is up to your own interpretation.
What if I want to have some auxiliary server app (written in Java) running somewhere in the cloud, e.g. AppEngine, to connect to the realm DB. Is that option excluded?
Your Java application will currently not be able to communicate with a Realm on the server-side.
NodeJS only.
Even then, the "synchronized" Realms that auto-update all data between devices through to ROS to reflect whatever is in the ROS is a paid feature.
Basically, Realm-Java currently only supports Android. As it said in the docs.
As for communicating with a local Realm for the server side on a Linux via the NodeJS API, sure, go ahead.
For the latter purpose - is NodeJS server-side app supported?
NodeJS is able to write to Realms on Linux machines. Possibly also Mac OS.
Free version is local Realm only. Paid version is synchronized Realm stuff through the ROS.
We are a group of 6 students in the last year of our studies.
We have to add new features on an existing web application. One of the most important feature and in our opinion the hardest one to implement is the following : the web application has to be functional even when offline.
As for, you must be able to consult data, make changes to the data, and when your device will be able to connect again, the app must try and synchronize with the online database. The current application use the following technologies : apache tomcat / mySQL / Hibernate / JavaEE / JavaScript / Ajax / xHTML & HTML5.
Considering that the main devices that will use the application are mainly digital tablet, smartphones (windows and android, not iOS for now), and windows PC ; my main question is the following one :
How can you do this kind of thing ?
I've done some research and it seems like you have to do a 'second' application, which will use mainly HTML5 to consult data while offline and JavaScript to control what the user is doing and what he can do. But we have no idea about the synchronization. It seems like SQLite could be of use as well
I know this is a general question but we are in the phase where we try and make sure everyone understands what the next steps will be. Thanks for your help and explanations.
Solution-1 : custom solution
There are api available to store data locally called indexDb in javascript which may help to store data.
For synchronisation i found that service workers may help.
Solution-2 : ready made tool
You can also try pouchdb but for this i think at server side you have to take apache couchdb database. I have not used it but would like to try this once.
Take a look at the Service-Worker API. Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled. It's the next generation of giving users an offline experience after the App Cache.
The Service worker - in combination with local storage or even better WebSQL or a polyfill like localforage could be a way to realize that kind of application.
Downside: Service-Worker require SSL, no way around that. Second, only latest chrome and firefox support these technologies.
You might lookup PWA Progressive Web Application as a keyword, which describes / and uses exactly that kind of technologies.
I would like to know whether a net server game for a game like packman can be held on google application engine easily? In terms of response speed.
I want to set a server which can manage the game tables in which the games will be held.
Each table will have two players only.
I don't understand if I can upload a java applet to GAE and how I'm doing so.
Any other suggestions about other free servers which can be suitable for a real time action games?
Thanks
GAE supports only short-lived connections (about 30sec max). Which means you can not have a permanent connection open between your client and GAE server. This effectively prevents push notifications from server to client, which are needed in most gaming setups.
To alleviate this limitation, Google introduced Channel API which enables you to push messages from server to client. However you need to use their javascript library on the client side. You could write an applet which calls javascript to access this library but this could be a bit of a kludge.
All-in-all, due to this limitations, GAE could prove not to be the right fit for your needs.
Update:
There is another reason why GAE is not fit for real-time communication between users: a client request to GAE app can be served by any server that Google chooses. Two users communicating could be connected to two different servers, even in different data centers (maybe even on different continents). To pass data between them you'd need to store all messages to datastore (slow) or to memcache (unreliable and possibly slow because it would need to propagate between servers/datacenters).
You can use permanent backend for fast responces and break through 30 response limitation. You manually can define instances of backends. If you set it to be permanent - it is always will be on. And you can use your own implementation of in memory cache for fast data storing. Not sure, but maybe performance of data store will be ok for you.
If DataStore ok and you don't have requests that can take more than 30 seconds - use fronend with high performance settings.
Yes you can upload applet. Just put it somewhere in war folder and make reference to it from your jsp/html
Well, if you need java, free for startup your project - I don't know alternatives to GAE
I will make a video chat website, but coming from PHP and Python for the web i have no experience with video steaming.
What do you recommend? Java or Flash? What's more flexible ?
I am thinking of even making a C++ server application for stream controlling with a PHP fronted. Since is going to be a high traffic website and performance is a must.
Can you point to some direction?
Any documentation? Framework?
I'm going to warn you: this is no small project. There's a reason why most prepackaged video chat websites and services cost hundreds of dollars a month.
First off, you need to pick your client side runtime. This is a major decision, since it will impact your available client base, and the cost of entry for your site. Flash is hands down the most pervasive, but Java is fairly prevalent in the techie culture. Silverlight less so, but you should check the latest statistics. Note that you should pick a particular version you're going to develop for, since the APIs may change, and market penetration is different.
Once you've developed the client-side code, you'll need to pick the server environment. If you use Silverlight, obviously you need to use C#.NET to develop the server side code (for the video streaming). Both Java and Flash as clients use Java as the server-end.
If you choose to go with Flash, be aware that you can either go with the official Flash Media Server, or you can go with the open-source Red5 server.
As noted by SEK, you should proceed with caution since providing a reliable streaming service might not be as easy as it sounds.
I would recommend reading about streaming (what it is/means, technologies, etc) and then moving on with the implementation.
Serving streams to clients
Solutions like the Flash Media Server, might give you less headaches. Red5, as previously mentioned is a 'nice' open source solution, although i am not sure about the capacity and stability.
You might want to check:
http://www.wowzamedia.com/ (Flash Media Server) - interesting
NOTE: Wowza Media Server 2 for Amazon EC2 is also available
http://mammothserver.org/ (Another Open source Flash Media Server)
http://fmsguru.com/ (Flash Media related tutorials)
Google is always your friend on this big topic..good luck.
I am interested in building a vehicle tracking system using GPRS. However, I have some questions for anyone who has done this before:
Is GPRS the best technology to use? Any problems people are aware of?
I am planning on using Java/Java EE - is there any better technologies?
If someone has built this before - do you have some examples of what to see for system requirements?
What are some good web resources you've found working on this?
Is there a step-by-step guide anywhere to getting started?
If you're just doing it for fun/personal use and Amateur Radio licenses are available where you are, look into APRS.
You can use a phone with a GPS receiver (internal or otherwise). External receivers are easier to use because they are addressed by an older Java JSR (http://www.jsr82.com/) and thus better supported in Java ME.
On the client side (phone), you can write midlets in Java (see JaveME) to access the GPS location of the device and then use the phone's data connection (GPRS or 3G) to make a HTTP request to a server that will track the location of the device. The only alternate I see to GPRS/3G is SMS but that makes things more complicated on the server side (you will need access to an SMS gateway with an GSM operator).
For the APIs required to build Java midlets, register with Nokia - they have a developer site that offers all the information you need. Of course, if you use another type of phone Nokia's stuff is not of much help.
There are some existing solutions for the client side - google for TrekBuddy - that can probably be used for a proof-of-concept.
On the server side you can write a servlet that tracks a device by device id and records the coordinates as sent by the phone.
If someone has built this before - do you have some examples of what to see for system requirements?
Some of the questions are too generic to answer, but to specifically answer this one. Here is one example.
Generally the software components (and a hardware component) that you would need are:
GPS tracking device - Capable of reporting the location over internet (or SMS). XeXun TK102 compatible devices are common in under $100 category, but there are plenty of other options.
Server and database - for storing the location / history. Java EE stack is a good choice here.
Map based reporting application - For viewing and analysing the location data. Typically a desktop, mobile or a web application.
Here is one simple open-source Java EE / Spring based vehicle tracking server, database and web-based mobile map application (2-3 above). It uses TK102 compatible GPS/GPRS tracking device (1):
https://github.com/mstahv/tindratracker