I want certain data from a iot endpoint or desktop implementation of app to be seen on mobile version of an app and visa versa. All endpoints should be able to access and change data as they see fit.
What are the ways that you can make data available to all endpoints? For instance I have a list of tasks that i make on the application on my desktop. Then I leave my house turn off my desktop and pull up the mobile version of the application. I want to see that same list. What are the ways to do this? I have considered a cloud hosted database but it kinda seems like overkill to have a database to store maybe 10kb of data as well as the cost associated with using their service.
Things I have considered but discarded because they dont fit-
google drive with a shareable googlesheet
The issue is that it is read only. Also speed and functionality is limited.
database running on desktop that syncs to mobile app.
The issue is that mobile app needs to be running at same time as desktop. also any changes the mobile makes to the data will not be saved to database if desktop version is not on.
Is there a way to do this without having a personal server running all the time to serve out data? Is there any database hosting that is free? Or is there something more lightweight than a database that would allow me to access and modify the data from any endpoint that has internet?
Depends on many factors so a little hard to give you the "This is clearly the best option" answer.
Easiest? Probably kick up a hosted database in a Cloud provider. I'm partial to Firebase/Firestore (Google) for mobile. They're extremely low latency, so any changes are reflected pretty much instantly, and they have an awesome SDK that makes it really easy to get up and running quickly. It's equally as easy on mobile and desktop. It does require a Google Cloud Platform account to use it, but the free tiers are super generous, so unless you're doing a ton of updating, it's probably free to host it (and you get $300 free credits for the first year of GCP).
https://firebase.google.com/
If I were to explain to a lay-person, who is somewhat familiar to Salesforce, the difference between Salesforce.com and Salesforce1, without delving much into the technical aspects, what would be the best way to do so ?
This?
Did you try googling you're question?
[EDIT]
This post, and this article sum it up better than I can.
The main points, boiled down are:
1) Developers can develop in any platform and it will work with SF1. Previously, it took sort-of a specialized knowledge to develop in SF
2) There's a command line that can be used to perform functions or get data and is specifically usefully and less time consuming for SF specialists and devs
3) "Committing to open source" means that the SF1 product will incorporate the best of the tech community into their product, for free
4) Integration with another cloud database company/system, Heroku, allows a broader range of data access - not just through the SF application
5) All of the SF product features will be available in mobile in SF1.
IDK - that's my shot at simplifying the explanations I've read. I could be misstating a technical detail slightly (which I guess is fine based on what you need) and I'm sure there are better ways of reducing the topic to more common language.
Hope this helps.
Both Salesforce.com and Salesforce1 can be accessed via a web client running on a PC, tablet, or phone.
Salesforce1 is optimized to work on a small touchscreen and can have functions via 3rd party apps to access iOS or Android features like GPS location data.
firstly I apologise if this is a ridiculously simple question to answer but it has been bothering me for a while.
I am trying to understand what salesforce actually is, I mean in technical terms. I have read the websites documentation and the wikipedia page but I am trying to understand what's behind all this fluffy terminology.
My understanding is that salesforce is a cloud based database which stores a very high volume of information and all salesforce apps consists of scripts that query this database and model them in different ways depending on the intended application, is this correct?
Thanks !
Software as a Service (SaaS)
To get program you need to download it, install, configure and so on. If your system have a lot of users it's very hard to configure ans support single user installation.
Imagine that you improved application, new release for example. You need update every instance.
With SaaS model you have a shared web application, that do the same thing as old downloadable one. But it's much easier to support it, because ideally there is just one instance of it.
Salesforce is a company that provides its own system by SaaS model, but not only. It is also a platform for developing new applications.
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.)
Speaking entirely in technology-free terms, what is the best way to make a mobile friendly site? That is, I want to make a site that will work on a regular computer but also have mobile versions of the pages. Should I rewrite each page? The pages will probably have different functionality, so should I rewrite the backend code? Should it be an effectively different site with the same database?
On my site, I detect user agent, and for known mobile browsers I serve a different stylesheet, with some larger/less necessary items left off some pages. The backend doesn't really change.
I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.
Good luck!
This is a pretty broad question, but here goes:
If the site is primarily about the content, meaning it's not so much a service you use as it's a publication you read, then I'd try to avoid publishing two sites wherever possible. Concentrate on simple presentation using mature technologies that mobile browsers can handle fairly well.
If it's essentially a software application delivered via the network, then things get trickier, because you're going to want to consider the UI of the mobile device, and how it differs from the desktop.
This should go without saying, but either way, if you have many mobile users, you should keep that in mind when you author content for the site. Formats, length, voice, etc.
In addition to the WURFL / WALL capabilities system that todd mentioned, there are Java Server Faces libraries available that use alternate WML renderkits for mobile phones.
One way I have done it in the past was to make sure my data was abstracted well in the data tier and then use separate middle tier models to pull what was appropriate. In my case the application was a weather application and the display methods of the target devices were really limited so we opted to only show the user the essentials on the mobile devices while the website was full featured. That was probably 10 years ago when WAP was big. But these days with devices getting bigger screens, better bandwidth, you may want to consume and display the exact same data with a different view model.
I never really know what type of application will need to consume the data in the future. We do a lot of apps across platforms but the domain model rarely changes. So I end up using the same middle tier objects where I can and pulling that data in different clients. A good example of this is a recent project where we had a rich internet application (widget), a full website, and a web service consuming the same data. Data abstraction in the middle-tier really shines in this environment.
On a very high level of abstraction, there are two main caveats with mobile devices: (1) their screen is small, (2) their network connection is intermittent. This basically means that your need to present the content so that it looks fine even on a small (variable size) screen, and preferably make it cacheable too so that your users can browse the content while offline. Then there's also the problem of low bandwidth and high latency, but those are slightly less important nowadays.
This is a very thorough overview of how to make a site mobile, though i hope its fair to say that there will always be different requirements for anyone seeking to go mobile. If you have a Blog, then you could just as easily make it mobile friendly using Mippin Mobilizer; its free, provides branding customisation tools, and with a big audience already browsing a wide mix of mobilized content, there's opportunities to generate advertising revenue around your blog.
This is because the Mippin Mobilized blog then becomes part of a much wider community of content, people, news, blogs, listings, all connecting around content, and much more at the mobile site:
http://mippin.com (on a mobile browser.)
Take a look at the Mobilizing tool because it shows off what the site can do in a second:
www.mippin.com/mobilizer
Only if you have a blog of course...