I could not think of how to best phrase my question, so what you think I'm asking is probably not what I'm asking. Pretend that I've got three working apps, but the needs of this fourth one are a little different, so I'm asking for advice / best practices, not how to write an SQL statement, code a listview, customize a viewcell, or how to bind to a datamodel. I've got all that.
The TLDR version:
What I need is a sane way to know when the user is done entering his data so I can push it to my server.
I know that there are people out there who have solved this problem, so I'm soliciting your advice. If you also did not want to do a save on every keystroke, I'm especially interested in your recommendations.
Here's the slightly more detailed version:
I'm writing a companion app for part of our desktop software, which uses a proprietary data server to store its data that I can access from the mobile device. In my previous apps, I have a screenful of controls. The user enters/modifies data, and I know to save to my local sqlite table when they exit the screen. It's basically a transactional model, and I only upload the data to our server when they press a button to do so. Works great.
However, for this app, instead of entering a screenful of information, the user is just entering numbers in a list. Think inventory: user has a list of products and quantities, and they update the quantities to match what they've got. The user will not leave the data entry screen often, and is likely to turn off the device, or kick the app out of memory without "going back", so my datamodels can have unstored data.
I have entry fields in a listview. I need to push the entered data to my sqlite table, then on to our proprietary data server. I would have thought to do it from the property setter in my datamodel, but sadly that gets called when the datamodel is initially bound, AND on every keystroke.
I know that there are lots of people who have coded data entry in a listview, I've read all the posts to figure out how make the viewcells work. I am primarily using Entry controls, and I have tried using TextChanged, Completed, and Unfocused. Each one has some sort of issue that makes it an undesirable solution "out of the box". I've got some ideas and know how to solves parts of my problem, but am hoping someone out there has a much better solution than my collection of little hacks.
Obviously there's a ton of details (and complexity) I'm leaving out. I am using a view - viewmodel - model architecture, but am not using MVVM or any similar framework. My solution needs to be in "vanilla" Xamarin Forms.
Thank you so much for your help!
I would comment but I don't have enough reputation, so here it goes.
Is there a specific reason a button can not be added to the page (below the list view), so that the user can press it when they are done taking "inventory"? I'm assuming this is part of the complexity/details you are leaving out.
Without a button, you could make the data save/push happen using an Unfocused event on each entry field. If the user filled in a value for each entry control, the unfocus event could call the method to save the data. The code-behind would get a bit cluttered and it could be messy if you have a long list of entry controls, but it would get the job done until you find (or create) or better way.
Hope this helps.
Related
I've gone through several tutorials on Flutter and I find that they cover basics just fine but there are some nagging aspects of good design and good architecture that are consistently missing. I'm writing my first actual (not toy) application in Flutter and find myself running into these missing points.
Global data. Once a person installs the application and tries to use it, I ask them to log in / create an account, since this is an application specifically for managing groups of people. I'm using Firebase on the back end, and the package to do authentication winds up returning Future<FirebaseUser> from everything. So, yes, when it comes to building a Widget that uses the user's data, I can use a FutureBuilder. That said, it seems weird to have to keep typing boilerplate FutureBuilder code to dereference the user every place I want to use the user's ID to look up their data (what groups are they part of, what actions do they have pending, etc.). I really feel like there ought to be a way to invoke the future, get the actual user object, and then store it somewhere so that anything that wants a user ID for a query can just go get it. What's the right solution? I can't believe I'm the only person who has this problem.
Updatable data. I've got a page where I list the groups the current user is a member of. The user, though, can create a new group, join an existing group, or leave a group. When they do that, I need to redraw the page. The list of groups comes from running a Firebase query, so performing an action (join, leave, etc.) should signal the app to redraw the page, which will have the side effect of re-running the query. Conceivably, one might make the page dependent (how?) on the query results and have it redraw whenever they update, and instead have some widget somewhere that keeps track of the query. There's another answer here that hints that this might be the right way to go, but that's really concerned with relatively invariant data (locale doesn't change all that often for a single user). So, again, I can't believe I'm the only one who does this sort of thing. What's the best practice in this case?
I've been thinking about the applications for goangular. In the need for immediate storage/database updates, such as a chat application or stocks application etc., I can see how goangular can be extremely useful in the sense of SignalR methodologies. But could it be applied to the traditional form with ten fields and a save button on it? All I could think of, was the traditional form, with ten fields on it -less the save button. If all ten fields are on the scope of the controller, than there would be no need for a save button. Every change of a field would be commemorated to the goinstant storage. Now having said that, how would one UNDO lets say any changes to those ten modified fields? Control+Z ten times? Not so robust. Any ideas on a UNDO all Changes button for such a form? (desperately trying to expand the bonds of real time database transactions)
I'll attempt to answer what I believe to be the spirit of your question first.
Most of the time, when using GoAngular, we're focused on synchronizing application state. Aka: Active clients sharing session data. Inevitably we drift into the territory of long-term persistence. At this point, rigorous validation / sanitization become a necessity, which we can't discuss without some context.
Let's say our user is completing their profile. This profile will be used to create a User model, which we will persist. Now that we have context, it becomes clear that we shouldn't persist a partially complete form, because it wouldn't represent a valid User model. We persist the form once it is complete, and valid.
Implementing this is as simple as creating a custom $scope.onSubmit method and validating the form input before calling $save on our new $scope.user model.
Undo would be easy to implement too, if you use $scope.users.$add, a key will be generated and returned, you could use this key to remove the new user. If you wanted to roll-back a change, you'd need to implement some system for versions, and roll back to the previous version of that User.
Hope I've answered your question in here somewhere :)
I have a small APP which allows users to view information on Beers and Beers they have tried for a local Bars Beer Club.
I have 4 Views. Beer Menu, All Stats, My Stats and Settings.
Originally, I thought to pull all of the data via a web service and return xml at initial load of the app, and use it throughout.
OR...
I could just pull what I need when I need it. This would result in just pulling the data I need, which would be faster, but it would result in more requests. What would be better:
a) pull all data, store globally, build views as needed.
b) pull only data I need, when I need it. This means if they click on a beer, I would make a request for that beers info. If they clicked on 10 different beers, then that would be 10 different requests.
What is better? Or does it even matter.
yeah, I think on mobile devices these kind of decisions to matter.
With these kind of concerns I think sometimes there is no right answer but here are a few pointers:
Use json, not xml (if you can)
it's less verbose and, depending on the data, could make a difference to the speed.
Do not block the UI thread
This is really a general guide to all app development, in my opinion. The worst thing you can do is block the UI thread.
Coding for a progressive UI that loads data separately will always be more fiddly than just doing a batch load, and then returning everything. But the extra work will really make your User Experience a lot more pleasurable.
Be clever about your requests
This kinda of carries on from the last point. I'm not saying do a million request, but do try and find a balance before less requests, and loading data as needed (which would suggest more requests).
Try and really think about how the user is going to use your app, and see if you can do some clever pre-fetching based on what you THINK the user might need more in the certain view.
i.e What is the most likely view to be used next? can you pre fetch the data for that?
This last part is really the fine tuning, and will result in a lot of trial and error. But the end result will hopefully be a really great app that just feels fast, and feels right.
I'd go with loading cached data on launch (if it exists) and then load fresh data in the background as needed. This keeps your app as responsive as possible. it's a balance between draining battery life on requests VS responsiveness and data availability. I think the balance is caching information with a timestamp (if the data changes, if not it's even better) and then update as needed.
I am writing an app for iOS that uses data provided by a web service. I am using core data for local storage and persistence of the data, so that some core set of the data is available to the user if the web is not reachable.
In building this app, I've been reading lots of posts about core data. While there seems to be lots out there on the mechanics of doing this, I've seen less on the general principles/patterns for this.
I am wondering if there are some good references out there for a recommended interaction model.
For example, the user will be able to create new objects on the app. Lets say the user creates a new employee object, the user will typically create it, update it and then save it. I've seen recommendations that updates each of these steps to the server --> when the user creates it, when the user makes changes to the fields. And if the user cancels at the end, a delete is sent to the server. Another different recommendation for the same operation is to keep everything locally, and only send the complete update to the server when the user saves.
This example aside, I am curious if there are some general recommendations/patterns on how to handle CRUD operations and ensure they are sync'd between the webserver and coredata.
Thanks much.
I think the best approach in the case you mention is to store data only locally until the point the user commits the adding of the new record. Sending every field edit to the server is somewhat excessive.
A general idiom of iPhone apps is that there isn't such a thing as "Save". The user generally will expect things to be committed at some sensible point, but it isn't presented to the user as saving per se.
So, for example, imagine you have a UI that lets the user edit some sort of record that will be saved to local core data and also be sent to the server. At the point the user exits the UI for creating a new record, they will perhaps hit a button called "Done" (N.B. not usually called "Save"). At the point they hit "Done", you'll want to kick off a core data write and also start a push to the remote server. The server pus h won't necessarily hog the UI or make them wait till it completes -- it's nicer to allow them to continue using the app -- but it is happening. If the update push to server failed, you might want to signal it to the user or do something appropriate.
A good question to ask yourself when planning the granularity of writes to core data and/or a remote server is: what would happen if the app crashed out, or the phone ran out of power, at any particular spots in the app? How much loss of data could possibly occur? Good apps lower the risk of data loss and can re-launch in a very similar state to what they were previously in after being exited for whatever reason.
Be prepared to tear your hair out quite a bit. I've been working on this, and the problem is that the Core Data samples are quite simple. The minute you move to a complex model and you try to use the NSFetchedResultsController and its delegate, you bump into all sorts of problems with using multiple contexts.
I use one to populate data from your webservice in a background "block", and a second for the tableview to use - you'll most likely end up using a tableview for a master list and a detail view.
Brush up on using blocks in Cocoa if you want to keep your app responsive whilst receiving or sending data to/from a server.
You might want to read about 'transactions' - which is basically the grouping of multiple actions/changes as a single atomic action/change. This helps avoid partial saves that might result in inconsistent data on server.
Ultimately, this is a very big topic - especially if server data is shared across multiple clients. At the simplest, you would want to decide on basic policies. Does last save win? Is there some notion of remotely held locks on objects in server data store? How is conflict resolved, when two clients are, say, editing the same property of the same object?
With respect to how things are done on the iPhone, I would agree with occulus that "Done" provides a natural point for persisting changes to server (in a separate thread).
Say I have a TODO list iphone app, that can be edited/viewed from both a web application and the iphone application.
When on the iphone, when a user views all his todo lists, or sub-items, I would think that each time the user views a particular list it shouldn't be hitting the web applications API every-time, but rather cache locally the values and only hit the web when things change.
What strategies are there for this type of scenerio?
I agree with you in your dirty-otherwise-do-not-contact-the-server point. And I think this point is pretty straightforward and easy to implement.
However, be careful in this scenario: it gets dirty but at the same time, the device cannot reach the internet. In this scenario, I suggest you check the internet accessibility on a frequent basis (even when your app is in the background), and try to reach your server and update whenever possible.
This is a tricky problem. I'm currently working on an app that needs to perform a similar synchronization, and I haven't decided how I want to handle it yet.
You're right in that you don't want to be hitting the web repeatedly. It would slow the app down considerably. Keeping a local cache is the way to go.
One drawback is that the user could change/add an item on the web and you wouldn't see it on the phone. You'd need to have a refresh button (like in the Mail application, for example) to allow the user to get the changes.
Then you have an issue with conflict resolution. Say the same item is edited on both the phone and on the web. How does the user pick which one to keep, or do they get duplicated?
I think the best way to do this is to replicated your server's schema in CoreData. Then load a given element from the local DB, and in the background go out and check that element for updates if the device has an internet connection. You're hitting the db each time, but the user is not slowed down by the process.
You should not query the internet everytime you view the list.
But when you make updates to it, or edit it, you should update the server as well. That will make your life a whole lot simpler. That way when the user updates an item that he deleted in the web server, the server will just throw that request out...