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
Related
I want to communicate with an NT3H211 tag from nxp. it supports ISO 14443.
I'm not sure how to do this in java using the ACR1255U-J1. There seems to be some drivers on the ACS website but it is not clear to me.
see page 45 of http://www.nxp.com/docs/en/data-sheet/NT3H2111_2211.pdf
How can I send e.g. WUPA and GET_VERSION via the reader ACR1255U-J1 from windows?
Are there more DEV friendly smartcard readers out there?
How can I send e.g. WUPA and GET_VERSION via the reader ACR1255U-J1 from windows?
You would need to use/develop an application using the PCSC command interface on windows. This works through the CCID standard driver provided by windows to interface with the ACR1255U-J1 over USB. There's open source Java implementations online like this one that will allow you to start getting familiar.
Are there more DEV friendly smartcard readers out there?
The ACR1255U-J1 is actually one of the more dev friendly readers on the market. The problem is that the superset of APIs exposed can be daunting to unfamiliar developers. Flomio offers a simpler SDK for mobile devices and web clients to get devs started quickly. It's based on a subset of APIs focused on just scanning a tag. More complex exchanges are then concealed behind a second layer of APIs. This reduces the learning curve and often devs are up and running in a couple hours. You can check this Forum for further details on how this goes.
I am new to mobile application development and wanted to know from experts here on how they approach the server-side design. I need to support cross platform clients (iOS, Android, Windows) and require a scalable backend architecture.
What are the widely deployed server-side strategies
Are there any Mobile specific open source server-side technologies available.
What factors people consider for mobile application back-end.
I agree with half the answer above. You should use REST architecture - it is the most straightforward way to go. I use Ruby on Rails for my mobile projects. It is quick to start building the server code and see it working in somewhere like heroku.com almost instantly.
So I'd pick the following:
ruby on rails - worth your time picking up
heroku.com for deploying / or EC2 if you pick the Rubber gem
Google App Engine is another great option if you know some python / java
REST architecture
store all your heavy images etc with Amazon S3. They have some great SDKs to work with.
get yourself some JSON libraries to communicate with your server
on iOS:
use MKNetwokKit (it will save you lots of trouble down the road. it helps you cache and its a nice architecture all around).
if the app is small, try a data model based on NSArchiver instead of CoreData (SLOWWW). Mogenerator is a good start (this isn't server related..)
If you hate writing server side, I'd advice you to checkout Parse.com. Completely mobile only development with all server code handled for you. For big projects, you really should write your own server stuff.
Some extra things I'd consider:
how would the security work? just a session token in the HTTP header?
tier your app -- networking / MVC
what happens when you're offline? - this is currently something we're dealing with after not having thought early - pain.
I've had good success with creating a server using REST web services and XML data, but would recommend JSON instead. You can create this using Java and host it using Tomcat. This is widely deployed and widely consumable by multiple mobile and even non-mobile technologies.
A couple of factors to consider:
* You'll probably want it in a DMZ and being Internet accessible so think about firewalls, reverse proxies, and encryption via SSL.
* Will you host the server or sell the server to customers? Hosting is easy. If selling, there are many more considerations.
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.
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.
We are in the middle to evaluate the technology choice to re-design an operator console application. The operator console as a hosted contact center has the abilities to queue the inactive calls, and hold, answer, transfer the active calls.
The legacy operator console used Java Swing. We want to use the latest RIA technology (Flex/Silverlight) to retire the legacy one. But the question is Flex/Silverlight can implement the functions like hold, transfer the calls? Based on my experiences, Flex can listen Java socket to receive XML data? Does it work well to receive voice data? Thanks.
Flash / Flex does have native access to the computer's microphone with the introduction of the latest player / AIR runtimes. But, that is probably not what you need.
Yes, Flex supports open sockets and can listn to a server. To receive voice data, you'll be best served using something on the server side, such as Flash Media Server or Red5.
I'm not sure of the technology to integrate such technologies with a traditional phone lines, though. You may look into Ribbit APIs as one solution. I was under the impression that Ribbit used Red5 under the hood; and it designed for these type of telephony applications.
You can use flex and Ribbit for that. Ribbit is a company that offers VOIP solutions for web application. I have used in couple of projects and it's really good.
Here is the link to their deve zone (htey support several technologies):
http://developer.ribbit.com/development-center/flash/flash-center
Hope this helps.