I need to track and update download status(start,pause,play,done) of multiple files in a list that I get from some Api (can't share), onto a RecyclerView.
I am also getting a fileId so each file can be distinguished.
I need download tracking based on the fileId because the Download list is also searchable, it means that the position of items will change and so we can't rely on position based ViewHolder refreshing.
Also if for some reason you close the app, and then go back to the list, search the file, it should show the file download status.
Now there are three options :
a) WorkManager based implementation (how this option can be implemented?)
b) PRDownloader (how this option can be implemented?)
c) Or Android's download manager? (Need to be sure that we need to show progress of multiple files at
same time in a list.)
Which one is better and more reliable?
Which one is the shortest method?
Also can someone share if you have code based on work manager?(how
will you manage to relate fileId to workManger's work id. Do I
need to make a DB table for keeping track of downloads by the Worker?
How to use LiveData from workManager, iff we can in the ViewHolder )
[Reference to Blog/Code/Repos will be most helpful]
Answering my own question(strange!).
I used Fetch Downloader Library
Initialized and used the "Fetch Instance" as a Singleton
Added the download using tag (Maybe I wrongly used the tag. It was supposed to be used for group of downloads. But I used one tag for each download. But it worked.)
Now I did following in the ViewHolder's bind() method :
Took the file Id as a "tag" and removed the FetchObserver linked to
the "tag" i.e. Id using the method of "Fetch Instance" (//will update
the method)
Then again find the download in the "Fetch
Instance" using the Id as "tag".(getDownloadsByTag() method)
If there is a download, you will receive a downloadList whose 0th
element will be your download because I am using one tag per download
and not for group.
Now add the FetchObserver again for that
"tag".
Inside the FetchObserver's lambda, update the progress and other values.
Note : The code can not be shared for non-disclosure purposes. Can share small snippets if you find this confusing.
Related
In my project a wearos app communicates with a handheld mobile app using dataitems. My wearOS app sends data by placing and changing a data item in the data layer.
Before placing the item I want to load/get the item before potentially overwriting its content. I can recieve it using dataClient.getDataItems(). Yet to me this just seems not optimal, I wanna use dataClient.getDataItem(uri). In order to get the specific item I merely need the uri.
uri format: wear://<node_id>/<path>
The only thing I dont know is the node_id of my creator node. Through logging I have seen, that, even doe I create a new DataClient everytime, when I put a new item to data layer, the node id stays same. Yet I couldnt find a way to access the id.
I feel like there should be a simple function like getLocalNodeId() to get the missing uri part. Am I wrong?
No idear, why that took me so long to find:
var node_id = Tasks.await(getNodeClient(context).localNode).id
According to a response made by Yigit Boyar from Google, Live Data is not the best use case for a chat app, because it may lose displaying some items if they come at the same time. He recommends using the new Google's Paging Library. I've been using ItemKeyedDataSource for my inbox(all the people that have message the user), and the inside chat(the messages themselves). The problems are the following:
1- From the chat, when the user scrolls downwards, the user retrieves old messages, which means that the insertion of those messages should be in position 0 of the adapter, not sequentially like the paging library does. How can I alternate the position of the inserted items to be sequentially for new messages, and in position 0 for old messages?
2- From the inbox(people that have message the user), again I'm using ItemKeyedDataSource here, the problem is that I want to maintain the multiple document listener from the repository (I'm using Firebase Firestore), so I can detect every time a new person talks to the user. The problem is that callback.onResult is called only once, and fails when Firebase sends another user. How can I maintain an update-able list?
I understand that this answer is probably too late, but maybe it can help someone in future.
Position of item in RecyclerView is determined by the position of corresponding data object (of type T) inside PagedList<T>. PagedList is designed to look alike good old List<T>, but can be thought of as an "endless" list of elements.
PagedList gets its elements by pages on demand through something called DataSource.Factory. A Factory is used because DataSource by itself can only grow in one direction. If you need to prepend elements in PagedList, or change or remove existing elements you must invalidate the DataSource and a new instance will be created through DataSource.Factory.
So, to insert your data elements where you want them you should implement your own DataSource and DataSource.Factory by subclassing these base classes.
Note: Room, data persistence library from AndroidX, provides facilities to automatically generate instances of these classes for your data. You can write SQL query like this:
SELECT * FROM messages WHERE threadId=:threadId ORDER BY timestamp DESC
then get DataSource.Factory from this, use the factory to create LivaData<PagedList<Message>> and finally use the paged list to display messages in a RecyclerView in a chat application. Then, when you insert, update or remove data inside DB these changes will automatically propagate to the UI. This can be very useful.
I recommend you to read a few related examples a do codelabs:
https://codelabs.developers.google.com/codelabs/android-paging/#0
https://github.com/googlesamples/android-architecture-components/tree/master/PagingSample
https://github.com/googlesamples/android-architecture-components/tree/master/PagingWithNetworkSample
We all know segmented control that is IOS but not in android. So I have an application that need something like that. For example let suppose I have a list of students and teacher marks the student either absent or present. and on click of each option there is a service call . for this I am using a library which is as follows:
compile 'info.hoang8f:android-segmented:1.0.6'
As I told you I have a list of students so in list I have the following case;
Case 1: If the teacher review the attendance the of last day , I fetch a list of students that are either absent or present. So on this , the segmented control that I am using in list fires the onCheckChangedlistener which run the code which is also performing some task , where as I only want to perform the task only when user change the listener. In short listener should not fire when I change any check pragmatically. and Also it fires the onCheckChangedListener multiple times. which creates problem for me :
So I have couple of question:
1) what can be used in android in place of the Segmented control library as I stated above.
2) what is possible workaround for this problem. I tried using flag but I am working in getview of listview.
this is a good library in response to what you achieve. I have used this and found the similar problem. So hence by putting flag , and making a raw check over it does a work for me . But As you are using list, i think you can not achieve what you are looking for.
I will suggest to use the radio button to get the check or you can make your custom control like this and see this library
I realized that when calling "createFile", it creates a new file even if its title is an already existing title.
What am doing now is to search for the file first and if i can't find it, i create it. Two methods for a simple problem.
There is a better way to create a file overriding it if already it exists?
Google Drive is actually a 'flat' model, where every object is identified by it's unique ID.
So, when an object (file/folder) is created, it gets a unique ID. The object may/not have content. Everything else is 'metadata'. The tree structure of popular OSs is actually 'faked' by metadata links (parent links). That means in Google Drive you may have multiple children with the same metadata (title/name) in a parent object. And you may also have multiple parents for any child object (single object appears in multiple parents' folders).
All this rant means one thing for your situation:
Once you create a file/folder and get hold of it's ID, 'creation of a new file with the same name' can be accomplished by modifying it's content and/or metadata (you can see a typical example here).
If you take the path of delete/create (which is also possible, but had not been until recently), you are actually:
1/ modifying the original file/folder's 'trashed/deleted' metadata
2/ creating a brand new object with a different ID
Think twice before you select the method you use. UPDATE method is a 'one-step', approach preferable in async environment (create MUST wait for successful delete). On the other hand, if you use DELETE/CREATE approach you may be able to take advantage of the fact that 'trashed' object will be around for a while.
Good Luck
I think files are uniquely identified by their ID in the Drive API. Therefore you have no way to control for the title using the drive API itself. So doing it yourself is probably the way to go.
EDIT: The ID is what is important with all that synchronisation happening. A title could change easily therefore using it as a unique identifier would be a bad idea. Hence the unique ID.
What you could do if the file already exists is either remove it and replace it by the new one (bad idea I would say) or simply add an extra number at the end of the new file that will be added to the folder.
My music app is referencing persistently stored data. All are currently stored as text files:
Favorites - single text file array. App starts, reads the text file, stores in memory. Array is checked when ListView is expanded. If array changes text file is rewritten.
Last Played - single text file array list. Updated every 5 seconds. Retains the history of the played songs to allow the user to return to any album and resume position.
Playlists - currently individual text files, one for each list. List of playlists generated from file names when required. Each playlist text file has array list inside it. Read Write when required.
Most Played - single text file array list. Updated once per song played.
I am wondering whether this data would warrant the need to change to a database, or whether I have taken the right approach. I don't foresee the need for adding additional data so this should be the most I would need.
Advice please!
You can store the text files in SharedPreference and it should work well.
Database if preferable if a lot of data needs to be stored. Using a database is more optimal than parsing a string.
The correct approach is to create a class for each of the things you want to represent, e.g. favourites. Each class has a save() and reload() method. The point is that you can change the underlying storage mechanism in the save() and reload() methods without having to change the rest of your code. Imagine in the future, you want to enable saving to Dropbox. You would simply change these methods and your app would just work (OK, you'd need to add stuff to get Dropbox account details but you get the idea).
You could go further and define Interfaces for loading and saving. That interface can use a single class responsible for nothing except saving and loading. As long as any consumer and provider classes adhere to the interface, you can mix and match, and even implement storage approaches yet to be invented, without recoding your app. You only have one class to work with if, and whenever, you change your storage approach.
class StorageManager(){
enum DataType {Favourites, MostPlayed, PlayList };
...
public save(DataType dataType){
if (dataType == DataType.Favourites){
saveFavouritesToDB();
...
...
}
This approach gives you maximum flexibility, maximum future proofing and better maintainability.
I think it would be better to go with Database.
The database should provide you with some optimizations, performance improvements and basically you don't have to reinvent the wheel (doing read / write operations on the disk, use some buffers before rewriting, and the like).
Plus, I think you will love the way all code will be organized and split into its own layers once you start using this way.