I'm planing to make android app the need of it is to recognize building in the city .
I need help in choose the most important unique features in the buildings ,such that the size of the features stay small as it will not be a practical application if the size of the database become large , is running the application offline possible or i should send the features to remote server for processing the similarity between the pictures ?
Actually, you could choose some simple but effective features(building logo, the foreground of the building) for recognizing offline.
In order to make the result more accuracy, you cound send the GPS information back to the server.
Do not only recognize the building by analyzing the picture, sometimes ,you can get more information from the Android.
Good luck.
Related
Say that I have to build a geolocalized app. What will happen is that:
thousands users will be using it at the same time
while the user will move around the city, will send his geo-location to the app. Then, based on that location, the app will send back an array of informations, update the screen and even, probably, a (google) map
So say, if there are 10000 users connected at the same time, all moving around, there will be really a lot of requests to the app, every second.
I'm doing a little research about the best tecnologies to implement, and I found that maybe using websockets would be a good choice. Is that true?
They say that websockets are good for:
Multiplayer online games
Chat applications
Live sports ticker
Realtime updating social streams
Are they ALSO good for the type of app I'd like to build?
WebSockets is only transport protocol and does not really solves the challenges you will face in development of your application.
First of all you need to decide if you are building Web app or Native app.
Then you need to consider scalability of your infrastructure in terms of concurrent connections as well as preparing responses - based on nearby locations (for example).
Few major questions you need to answer first:
How often geo-data will be sent.
How often updates of other locations should be updated on client-side
How you going to prevent cheating: If I send geo-location of airport while am in totally different place (as example).
On server side, how you are going to store locations data (mongodb has 2d indexing out of the box).
How you going to find nearest points, identify them and send to client?
Searching of nearby places - is expensive task, and requires a lot of optimizations like clustering of space, 2d indexing, etc.
Me and my team will be developing a POS system for a restaurant chain.
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders.
The mobile app should do this -
1. Waiters will take and track order.
2. The manager should be able to check employees's leaves,timings,etc.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Are we on the right track?
Can HTML5 help us in the mobile application?
How many do you willing to pay for me to give you the architecture? Just kidding.
Think of a retailer that:
Has only 10 kind of items
With sell only 5 quantity of each items each day
That has only 1 staff and it is his/her family
That sell only with cash and not electronic payments
Do you think that kind of retailer need a mobile application which can do POS with cloud computing support? Of course not. He/she maybe only need a book written manually with simple accounting debit credit to track his/her income/expense. But a big company like W*lmart will do.
If you want to make an application, make sure that you has the requirement. Why bother create something that is not needed?
If you want to make a general POS application, collect the basic requirement first. What they need. Will they do input by entering the item code, or scanning using barcode? Will they need to make a payment after the item being entered (typical retailer system), or they need to make a payment after they asked for the bill (typical restaurant system). It will later decide your architecture.
Now asking your question:
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders
As I have have said before, the architecture will depend on the device used and how the process be done.
The mobile app should do this -
Waiters will take and track order.
The manager should be able to check employees's leaves,timings,etc.
First point is your requirement but 2nd point. What? Track employee's leaves, timings,etc? It should be included in HR module, not POS module. Keep your application scope to the smallest and make sure that each of your module are in same topic.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Try it and you will know whether this distributed database design are good or not. Search for articles about pros and cons for this design and make sure you know the sequences before starting design.
Are we on the right track? Can HTML5 help us in the mobile application?
It is like a same question as: Can a keyboard help us type? HTML5 is a language used in any web - server programming. It is kind alike of rendering / layout technique. If you want to aim for modern browser such as latest version of firefox, then go for it. But really, do you know how HTML5 can help you, or do you know what are the downside of using HTML5?
Since this app will only be used by employees of the restaurant,
(not by customers), it would be safe to assume targeted mobile
platform, Android or IOS.
Since, the inventory, employees leaves etc is being tracked in
restaurant locally, the idea of using local DB which syncs with
the remote DB seems the right approach.
The menu of items and their codes should stored at central DB
server and fetched from there.
There are many remote desktop protocols used widely, e.g. VNC, RDP, PCoIP, RGS, etc. Taking a look at their specification, it seems that they provide different features, such as redirecting I/O, tuning display setting, etc. I've recently installed a thin client system at my company. By using RDP protocol, the users are complaining about slow update of their screens. PCoIP has also slowed down their IP telephony activities.
Now the Q is: How can I evaluate and compare the effectiveness of remote desktop protocols based on the quality of their user experience?
I'd try to steer away from peoples "gut feel" for performance and get numbers to do the talking.
I use a variety of benchmarking tools to evaluate the performance. Since it's about user experience you need to consider the type of user, Task, Knowledge, Power user etc.
I can't address what is the "best" protocol as it's really a moving target and has many factors, but our baselines are in a XenDesktop environment with ESX etc. We have images with SAS storage and EFDs for cache drives.
Now the Q is: How can I evaluate and compare the effectiveness of
remote desktop protocols based on the quality of their user
experience?
Tools I use are..
OSMark
It's a great tool I customise the tests to suit the environment eg. CPU intensive, Graphic and so on. I can then compare rendering of RichText, Web and 3D objects when I make changes to the environment and relate back to the baseline. Youcan also run the same tests on a physical machine to look at the variance.
Crystal Mark
Benchmark disk performance, good for "Internal to VDI" testing of a VDI disk\network performance.
If you have a Citrix Environment, EdgeSight for Load Testing is great as well.
While this does not address your problem in particular it might help determine your bottlenecks and create load on the system for other testing.
You may need to look into QOS for your telephony stream and seperate the traffic once your determine what is most important. Look at if you can change compression in your telephony system as well.
Hope this helps, or is useful to anyone passing through.
jezr
Here are my findings:
RAWC by VMware
LoginVSI by Login Consultants
and DeskBench
I am looking for some tips also, but came pretty much empty handed.
The best stuff I am using to benchmark the performance of RDP-like solutions is WireShark and a synthetic test.
Run WireShark, connect and do some (ideally scripted, for reproducibility and comparability) operations your users would do (go to menu, edit setting, ave a fullscreen refresh of some picture that is hard to compress and then some window maximize and minimize to see how big monotone screens are compressed and so on).
Measure the time between the click that starts the refresh and the complete refresh showing up ( when the data stops flowing)
Watch out for things like clocks, widgets showing real-time data and other stuff generating a lot of refreshes every second, that can produce some noise making it hard to evaluate the results.
I am an Android developer. I haven't developed J2ME applications before. I have a requirement in which the client needs a J2ME application which requires me to store around 10,000 (Each record would have around 60-150 KB of data) records on the mobile phone. The mobile app will also be tied up with a backend server using a REST based web service.
The client wants the app to run on a specific mobile - Nokia 5233.
I need the correct options to proceed. Currently I am using the RMS and LWUIT. I chose them because:
RMS - I am using the CLDC profile. I am not aware of any DB that can be used with this configuration. Apache Derby is supported only in CDC.
LWUIT - There are many cases in the application where the TextField requires event listeners, the StringItem in LCDUI doesn't seem to have any event listeners.
Please enlighten me. I'm not sure whether I am taking the right direction.
RMS is probably your only decent option for on-device data persistence in J2ME (unless you go for direct file access using JSR-75, however if you aren't signed, the user will see all sorts of intrusive error popups when using this API). 10,000 records at 60KB per record, i.e. 614MB minimum? I've never heard of a MIDlet storing this size of data, RMS is intended really for a meg or two at most.
Why do you need to use J2ME? The 5233 is a Symbian^1 device, maybe try a native technology such as Qt? Probably far more reliable for that size of data, and easier to get a nice UI too.
(By the way, what events would you expect StringItem to give? It's a display-only widget.)
If I want to implement CMS for Mobile Devices, what kind of points should take into account?
For example, make page size smaller, use optimized (small) pictures. Any other ideas?
Also what kind of rules can be applied while converting web-pages that WERE designed for Desktop Browsers, to the ones that are easily displayed in Mobile Browsers.
I know that Mobile Devices widely vary in there capacity and property, but still trying list out some rules.
Also any other ideas, suggestions, questions and advices are welcome on this topic.
Thanks for your opinions and answers.
Short foreword, all the things I'm listing below are something the main product of the company I work for already does or has worked out a solution for, the whole goal of this answer is to give you pointers.
Identifying the phone
When dealing with mobile as a web context, it's absolutely imperative you identify the phone correctly. That should be the highest priority. Here's couple of issues with identifying phones and their features:
Do not use userAgent.contains("iPhone") detection scheme. There's already loads of web bots and other applications which contain iPhone in their user agent string and thus you'd identify them incorrectly.
Not all phones even send User-Agent headers. However some of those send UAProf URL:s which contain all the phone's features in RDF format. Unfortunately this introduces the next two problems:
Obviously you won't have access to every single device data out there and you're bound to use public data repositories such as WURFL. These databases are however incomplete, slightly lagging behind or don't contain data you'd like to have. They are your best bet for initial data set though.
UAProfs lie. Yes, they contain false information - lots of it! Partly this is because the manufacturers forget to update the XML:s and partly because the UAProf files are written during the development of the phone and as we know, features do change during development.
When relying on a feature, make sure you're not relying on a specific version of a specific phone. For example BlackBerry has a feature called Tile which is basically a really fancy bookmark but you can't just serve it to all the BlackBerry phones, you have to identify the operating system version of the actual phone to serve the right variation of the Tile. Same goes for touch screen, iPhone wasn't the first one with touch screen and most certainly isn't the only one either - also don't expect a situation where the device has only one form of input, for example Nokia N900 has a touch screen, physical keyboard and even stylus.
Creating the actual pages
Thankfully this is something people have agreed upon and when creating the pages, you're supposed to use XHTML-MP. But oh how one would wish things were this easy...
All phones have differing level of XHTML-MP/CSS support. As an example, if I remember correctly, some older BlackBerries don't support background-color for block elements. Or header tags. We've also seen incorrect ordering of span elements when there's several in a row. Oh and for some reason tables are really hard. Basically, you have to go low on markup/styling tricks.
You can't test the existence of the feature by using the feature itself. If you want to detect JavaScript support, you could think that adding a bit of JavaScript to the page for that purpose alone would work, right? Nope, that crashes a significant percent of mobile phones visiting your site. Sure, new phones don't crash but not everyone has bought their phones in the last 12 months. Also mobile specific JavaScript API:s differ per manufacturer, as yet another example there's currently at least three different API:s for JavaScript-based geolocation detection, none of them interoperable with the other ones.
Add all these on top of normal CMS features (security, content management and transformation, caching, modularity, visitor tracking and whatnot) and you should have some sort of picture of how everything affects everything and how you really should consider the cost of making your own.
In fact even though this is sort of against the general spirit of SO, I'd strongly suggest for you to get a readily made solution such as ours and use that instead for your site building needs. After all, our product has seven years worth of specialized development under its hood.
A couple that we used ...
A cms targeted for mobile devices should be able to detect the device type and detect (or have a database of) screen resolutions so that content, particularly images, can be scaled appropriately.
The rendering engine should also be able to determine if the device can handle HTML or WAP and switch markup languages appropriately.
Paging capability on the output as opposed to rendering very large pages (if content mages are large) is also helpful.
Clean integration with the corresponding web site CMS (so content doesn't need to be dual produced) is also helpful if tere is, in fact, a corresponding large form web site.