I was wondering if it is possible to develop a text messaging kind of application similar to WhatsApp, but for between WP7 devices? What difficulty programming skill level am I looking at and what would be required to develop such an app? Thanks!
In general I don't think it will be really difficult to build an app like WhatsApp. (Although I only heard about the funcationality) So I will give you the information I think you should have at a minimum.
In the first place you need your WP7 app, which I think should have push notifications to notify users about new messages. (Note: push notifications work in batches, so there will be no instant delivery notification to the end user.) You should have a login system in your WP7 app, which makes users uniquely identifiable.
Somewhere you should have a central datastore where you can store users, messages, relations between messages (replies, forwards, etc.) (Note: If your app becomes as big as WhatsApp you should have a really good scalable datastore.).
I would use WCF to communicate between your datastore and the WP7 app. Probably I have overseen something right now, but this will give you a start for defining your applications architecture.
UPDATE 12:54
As i saw your comment about where to start I searched for some documentation:
There is a free e-book from Charles Petzold which covers alot:
http://www.charlespetzold.com/phone/
Also there are a lot of code samples and documentation on MSDN:
Main overview of WP7 development:
http://msdn.microsoft.com/en-us/library/ff402535(v=vs.92).aspx
WP7 code samples:
http://msdn.microsoft.com/en-us/library/ff431744(v=vs.92).aspx
You can have a look at the Sockets Support section, which may help you to get started.
Related
I want to create a realtime stock alert app where users can subscribe to specific stock instrument with target price. Once that target price hit, The subscribed user will be notified over the app.
A good example of such platform is Tradingview.com
For stock API's I will be receiving realtime stock quotes from My API vendor over.
As far my knowledge is concern, I'm looking at this app as Web socket OR MQTT pub/sub platform where users can subscribe to that specific instrument topic and get notified once stock price is hit.
But my knowledge is limited when it comes to thousands of users subscribing to thousands of alerts.
What technologies must be going at the backend for such kind of apps ? What must be the data flow ?
Bit late answer to this, I was working on something similar with all custom NodeJS server and instruments you want to subscribe on. It is very simple server and you can find it here https://github.com/markosole/yahoo-node-streamer
I am working on desktop App built on top of Electron which is used for subscribing to instruments, monitoring multiple instruments and creating visual and sound alerts for every instrument individually. I have not release Electron app source to the public yet.
Creating mobile app will be harder as it would require backround data and best bet would be using Flutter and Google Firestore to send alerts. Well this is very top level.. I will eventually make flutter app and share it on Github
Overlooking the fact that there are literally thousands of apps out there that do all of this already....
Your best bet might be to do one of two things:
1) Just send out the stock price and let the client app figure out the alert, or
2) Have a back-end system that just sends out the alert to the specific customer when their price point is reached.
Option 1 is something that MQTT could easily do. Option 2 could be done using MQTT, but its something of an overkill IMHO. MQTT is built for applications where one node is publishing data, and many nodes are subscribing to that data -- hence Option 1 is more in line with what MQTT was built for.
I'm contemplating to use Parse as a platform for my app, as I'm trying to avoid creating and managing the cloud infrastructure myself.
For the sake of simplicity let's say that my app will hook into an Exchange Server and will need to leverage some hosted Machine Learning service to categorize my e-mail and report on insights found.
I'm assuming that Parse would store my core data, while the hosted ML will store the "Big Data" associated with processing for insights.
I'm also expecting my app to receive push notifications generated by the hosted ML service.
Does this sound like a plausible way to go about it and leverage Parse, or am I better off developing the backend myself?
I think parse.com is the right place for you requirements, because they have everything you need like storage of core data, push notifications, cloud module which can be integrated with heroku, social integration, user management functionalities.
They also have large set of client libraries for desktop and mobile apps (node,java,.net etc...) also they have libraries of embedded devices.
The biggest advantage is that everything is setup, and you are focused on software development not on infrastructure things. This is my opinion.
I've been experimenting with the above stack and so far was really impressed. Seems like a viable path forward. The Cloud Code capability of Parse is very solid, and easy to work with. If you want to run services outside of Parse code this us also possible : just issue REST calls.
I noticed in the commercial API you have the ability to use branded map skins. How is that actually implemented on the app side? Are there "MapView" objects exposed? The commercial API documentation is not available online, but I would love to read it before I commit to purchasing a contract. I'm really interested in what is exposed by the REST Api also.
Glympse map branding is currently available only in the HTML-based Glympse viewer (i.e. a customizable experience for invite recipients or when viewing a Glympse group). There are a number of themable components, most of which are available with any registered Glympse app.
Unfortunately, the customizable map experience on the app side of things has not yet been released.
I working on a project were mobile users can receive alerts based on diferent factors, the server side will be implemented using the MVC framework.
My question is regarding the client side; what would be the most efficient way to send the alerts to the clients? is there any way to broadcast the alerts to each device or do I have to set up some system where each device pulls the data from the server on an interval of mins/seconds? I am afraid pulling the data every X secs/mins would create an unnesesary overhead on the mobile devices.
One way would be using SMS but SMS gateway services are expensive and not on my budget right now.
I haven't personally tried it, but this service might work for you:
http://www.airgramapp.com/api
It is free for limited use. Downside is it appears to be a separate install on the mobile device. This might means less control of the content of the message or its look. Upside is it looks quick and easy if you just need a proof of concept at this point.
I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.