I am looking to create an app with plugin functionality. What I want is to allow a separate plugin "app" to provide me with the view, and take care of the updating of the view that I will use in my list adapter. Essentially, I want the separate app to take care of the bindView and newView methods of my adapter.
I am looking at RemoteViews, but I am not sure if that is exactly what I need, if it would work, or maybe it's what I have to use, since it would be cross-process.
Thanks for your help.
RemoteViews is the only thing vaguely practical, because you are communicating between processes.
Performance will be awful. Getting a ListView to behave quickly when everything is in one process takes a bit of work. Going across process boundaries for every row will either be very slow and memory intensive. This is why, for example, ContentProvider returns its full result set on a query(), to avoid dozens or hundreds of extra RPC calls.
I strongly suggest you reconsider your proposed architecture.
Related
I want to know how to fetch data from the local SQLite database in the background with a callback in the main thread. Say, the callback should be in a Fragment. And I want to avoid using the Room library. Currently I fetch the data in the UI thread using SQLiteHelper.
I have considered various options and understood that there is no silver bullet. For example:
I could have used AsyncTask, but it should be subclassed and in case the activity is destroyed before the task is finished the data is passed to the destroyed referenced activity. As a result - a memory leak. Although, I restrict the screen rotation that lowers the chances of the Activity destruction, should I keep neglecting using AsynkTask?
Another option is IntentService. In this way I can fetch data from SQLite in the background and use EventBus for a callback. However, seems like it is an overkill for such a task. The plus - easy implementation.
CursorLoader with ContentProvider is the third option. I believe this is what I need. However, I believe the code could be verbose. I havent used these classes and after reading miles of texts, still dont know how to implement them.
What option should I choose? Please, provide me with a guided code in case you have one.
Please correct me, if I am wrong in some statements.
I have few gwt mvp design related questions:
Can we use event bus to switch views from one presenter to other via controller using custom event?
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can take a decision, which presenter to show?
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if someone has any thing to mention in favor of this.
PS: all my views make use of custom widgets and there is no gwt specific widgets(buttons, checkbox etc...) in views.
You can do anything you want, but you have to consider the consequences. For example, if you switch views without creating a history event, a user may be thrown out of your app when a user hits a back button expecting to see the previous view.
I very much like the Activities and Places design pattern. It takes care of all of the issues (history handling, bookmarks, tokens, etc.) You can also extend it to add animation effects when switching views on mobile devices - mgwt does that.
I have few gwt mvp design related questions :
Can we use event bus to switch views from one prsenter to other via controller using custom event ?
This is a bad practice, unless you have real good reasons to do that. Since you're changing the view without having an impact on the url, you won't know what is a the state of a view at a choosen moment, you cannot get back to a previous view in an easy way, and finally, people will have difficulties reading the code, since you're out of the "standard".
The only reference for you should be the url, you cannot assume data is loaded neither the applicatio is in a given state: each and any view may be the start of the navigation story for your users, so if you get information from any other source than the Place, you're probably doing wrong, especially if your source is an event. the only special case here is you don't want users to enter your app in a certain view state, so you 'impose' that another url is called before, and restrict the access to the view through an event starting from a given application state
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can
take a decission, which prsenter to show ?
as said before, you're reinventing the wheel. It's far better to adapt to the existing mechanism that is well thought and covers the majority of cases. You can put a json formatter to tokenize your url while developing so it's not a nightmare to put variables in. And when you're done, create a nicer regular url format
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if
someone has any thing to mention in favor of this.
depends on what you call a View. if it's the activitie's view then youm might need that in very few cases, it's better to inherit a basic view and fork its children for each activity (even if the view does nothing, time will show it will evolve differently): this is better since the base view contains what is common without the specifics of each child activity.
Finally if you mean a composition of widgets when you say, a view, then you should definitely reuse them, it will make you obliged to improove your widgets and compositions to be in a constant improvement, this will heop you for the rest of the project, and maybe for other projects
This is one of the questions that involves crossing what I call the "Hello World Gulf" I'm on the "Hello world" I can use SQLite and Content Providers (and resolvers) but I now need to cross to the other side, I cannot make the assumption that onUpgrade will be quick.
Now my go-to book (Wrox, Professional Android 4 development - I didn't chose it because of professional, I chose it because Wrox are like the O'Reilly of guides - O'Reilly suck at guides, they are reference book) only touches briefly on using Loaders, so I've done some searching, some more reading and so forth.
I've basically concluded a Loader is little more than a wrapper, it just does things on a different thread, and gives you a callback (on that worker thread) to process things in, it gives you 3 steps, initiating the query, using the results of the query, and resetting the query.
This seems like quite a thin wrapper, so question 1:
Why would I want to use Loaders?
I sense I may be missing something you see, most "utilities" like this with Android are really useful if you go with the grain so to speak, and as I said Loaders seem like a pretty thin wrapper, and they force me to have callback names which could become tedious of there are multiple queries going on
http://developer.android.com/reference/android/content/Loader.html
Reading that points out that "they ought to monitor the data and act upon changes" - this sounds great but it isn't obvious how that is actually done (I am thinking about database tables though)
Presentation
How should this alter the look of my application? Should I put a loading spinning thing (I'm not sure on the name, never needed them before) after a certain amount of time post activity creation? So the fragment is blank, but if X time elapses without the loader reporting back, I show a spiny thing?
Other operations
Loaders are clearly useless for updates and such, their name alone tells one this much, so any nasty updates and such would have to be wrapped by my own system for shunting work to a worker thread. This further leads me to wonder why would I want loaders?
What I think my answer is
Some sort of wrapper (at some level, content provider or otherwise) to do stuff on a worker thread will mean that the upgrade takes place on that thread, this solves the problem because ... well that's not on the main thread.
If I do write my own I can then (if I want to) ensure queries happen in a certain order, use my own data-structures (rather than Bundles) it seems that I have better control.
What I am really looking for
Discussion, I find when one knows why things are the way they are that one makes less mistakes and just generally has more confidence, I am sure there's a reason Loaders exist, and there will be some pattern that all of Android lends itself towards, I want to know why this is.
Example:
Adapters (for ListViews) it's not immediately obvious how one keeps track of rows (insert) why one must specify a default style (and why ArrayAdapter uses toString) when most of the time (in my experience, dare I say) it is subclasses, reading the source code gives one an understanding of what the Adapter must actually do, then I challenge myself "Can I think of a (better) system that meets these requirements", usually (and hopefully) my answer to that converges on how it's actually done.
Thus the "Hello World Gulf" is crossed.
I look forward to reading answers and any linked text-walls on the matter.
you shouldnt use Loaders directly, but rather LoaderManager
Is there a listviewObject.saveViewStates(view) function I can use? I have listviews, I have other listviews with custom adapters, but neither of these save states of the view. There is a lot of dynamically generated content in these listviews, so of course, when it that row goes outside of the view, the data is reset.
I understand the concept behind a viewholder, yet I am having great difficulty retroactively fitting my listviews with them. (nullexceptions, illegalstateexceptions)
Since the common way of holding the view is to pass the view, wouldn't it make sense that the listview had a built in function that simply accepted the view as a variable? I understand that the listview was created with limited memory in mind, it just seems negligent that there wouldn't be a way to save the states built in, in contrast to the webview - which is also built with limited memory in mind - the user can force enable/disable caching, do their own memory management etc.
Insight appreciated
The whole idea of the list is that it is dynamic and can be potentially long - so have lots of rows which are invisible. Therefore the aim of the adapter approach is to only keep as many views as visible on screen and fill them with data by running getView() - which should reuse views if no longer needed.
So when you take that in the account, it becomes pretty straightforward, that it's the data model behind (stored in adapter) that should get saved/reloaded and the list views should be rebuild when list is reloaded and filled with the data from the model.
This is more in-line with the list concept.
I have changed my app to use MVC and it has gotten pretty slow.
Description:
The application has a number of 5 composites, each composite represents different data and is not always showing
The app is using MVC and I am passing the model to each composite when an update occurs.
I am rebuilding a Tree (and all tree items) every time a notify is recieved, however, only one of the tree items would have changed, so this is possibly a waste.
Due to the style of the app I have to even notify() for insignificant things like changing the text in a text box or selecting a menu because I have a saved icon that turn to unsaved whenever something is changed in the tree Item.
All the composites are implementing the same Observer Interface, so all are getting updated on every notify().
Can someone give me some tips on what I should do to speed this app up. Which of the above might be more CPU hungry than others, ie, is rebuilding a Tree with < 20 items on every notify() going to use that much CPU time, do I need to re-design this? Should I create a seperate interface such as SaveStateChanged that will only notify the tree, or is this just a waste of time.
When an application is getting slow, then most time is often not spent performing the JavaScript calculations themselves (e. g. I don't believe, that just calling a lot of observers is a problem - it depends on what they do!). Very often, slowness is caused by things like redundant layout (e. g. when each of the observers causes a layout call). Sometimes, lots of DOM manipulations can also be a problem (mainly with Internet Explorer).
I would suggest to play a little bit with Speed Tracer, especially the redundant layout example. If that's not the specific problem in your application, you should be able to take a similar approach as shown in the example to track it down. Use markTimeline("String") to make special parts of your code show up clearly in Speed Tracer's graphs.
The first step you need to take is to isolate exactly where the performance problem is occurring. You've identified some good possible candidates, but you'll want to back that up with cold hard stats.
You may find you only need to address one of the above points, or that there might be another sticking point entirely
I suggest you get rid of the Observer interface in favour of something more finegrained. Look at the MVC architecture in Swing where a JTree is associated with a TreeModel and implements TreeModelListener interface to hear of changes to the model. The TreeModelListener interface has specific methods called by the model to indicate nodes changing, being added or removed from the tree. In addition it has a TreeModelEvent which provides even more data about which nodes are affected. If the model tells you precisely what has changed you will have a lot more scope for reacting intelligently from your listener implementations.