I'm currently going through Bloc bootcamp for ios development and I'm looking for a solution that will reload "new images" upon launch. Essentially it needs to automatically refresh and fetch new images without the user having to pull to refresh. We are building out a replica of instagram if that helps.
It sounds like you've already got the method created to accomplish your task, so it's just a question of calling that method.
I don't know what your code looks like, so I'll attempt a "physics for poets" example:
- (void)pullToRefreshMethod {
// there might be code for configuring the view, etc. in here
// your code to refresh
}
The simplest way to do it when it loads is in your viewDidLoad on the initial ViewController. Let's say your pullToRefreshMethod does other things in addition to refreshing. What you could do is take the code that refreshes and put it in its own method.
- (void)refreshInstagram {
// your code to refresh
}
Then, within your pullToRefreshMethod, you'd call it with:
[self refreshInstagram];
and in your viewDidLoad, you could call it there, too.
Without specific code, I can't give you a specific answer, though.
Related
I have a login view controller in which the user enters their preferences like whether or not he wants to activate certain UI features.
I store these as variables whose getters and setters directly access UserDefaults, here is an example of one of these:
class Preferences {
static var likesSpaghetti : Bool {
set (likesSpaghetti) {
UserDefaults.standard.set(likesSpaghetti, forKey: "likesSpaghetti")
}
get {
return UserDefaults.standard.bool(forKey: "likesSpaghetti")
}
}
}
So that whenever I want to set any of these I simply write something like this:
Preferences.likesSpaghetti = false
Now, my question is: Can I set these variables every time the user flicks the on/off switch or should I keep the preference represented as a local variable and then only set:
Preferences.likesSpaghetti = spaghettiSwitch.isOn
when the user segue's away from the loginViewController? Is every access of UserDefault instant and quick? or is it laggy and should be used mercifully?
Edit after closing this question: So I learned to not prematurely optimize, and that it is probably ok within the scope of a few dozen elements. So I should be fine. I'm going to just update every time the user modifies anything so that my code is a lot easier to read and maintain.
Thanks everyone!
Your code is just fine. Don't worry about such optimizations until you actually encounter an issue. Trust that UserDefaults is implemented smartly (because it is). There is nothing "laggy" about setting something as simple as a Bool in UserDefaults.
You also wish to review another one of my answers which is related to this question: When and why should you use NSUserDefaults's synchronize() method?
Actually userDefaults (it's originally a plist file) is used for this purpose which is storing app settings and that light-wight content creating a variable may consum memory if you have to configure many of them , besides not reflecting the new setting change directly to defaults made by user , may cause un-expectable old settings to happen at the time of change such as a localized alert or part of code (such as push notification callback) that check the same setting where the user thinks it's already reflected
Adding to both #rmaddy #Sh_Khan, if you think about the security aspect of it, NSUserDafault is exactly for the details which is app specific such as settings, preferences or some configurations which are not security sensitive while things like passwords, usernames and sensitive data are not recommended to store in UserDefaults. You should use services like keychain which is encrypted for such data.
I have following problem. In my app I'm downloading .xml file from server and then parsing it. I call both methods (get and parse) from application:willFinnishLaunchingWithOptions.
Right after parsing is posted notification. In main table view controller is observer and selector is supposed to reload table view. But it doesn't. ViewDidLoad in TVC is called before parsing is completed, also before launching screen disappears.
So my question is: Is possible to freeze application:didFinishLaunchingWithOption till all data are parsed? Thanks
No its not possible. What you could do:
Don't show your TVC. Show a loading Controller. This Controller will do the work with loading the data and parsing it. When its done you can call your TVC
For Example:
LoadingController has a instance of a Manager Class
The Manager downloads your file. ( Extra Communicator or something else)
Your provide success and failure blocks to the manager calls. Means, build a function with func downloadXML(success: blockStuff, failure: blockstuff). In the success your provide the parsing
When parsing is finished you show your TBV with the data
Feel free to ask or comment :)
I have the following code:
Button export = new Button("CSV");
export.addListener(new ClickListener()
{
public void buttonClick(ClickEvent event)
{
CsvExport csvExport;
csvExport = new CsvExport(_table);
csvExport.setDisplayTotals(false);
csvExport.setDoubleDataFormat("0");
csvExport.excludeCollapsedColumns();
csvExport.setReportTitle("Document title");
csvExport.setExportFileName("Nome_file_example.csv");
csvExport.export();
getWindow().showNotification("Document saved", "The document has been exported.");
}
}
I would like the notification to appear only after the file has been exported and downloaded, but actually the notification is not working, maybe because it does not "wait" for the statement
csvExport.export();
to finish. If I comment it, the notification works.
Does anybody have any suggestions?
Thanks very much,
You'll need to split the work into a separate thread, then provide a way to notify the user 'later'.
So, first, create a thread... if you're on Java EE, use the built-in thread pooling, otherwise use something else (we're on tomcat, we rolled our own, to allow us better control).
Then, when you're done, synchronize your thread, work your way back into your UI class (We use closures from Groovy, but you can make your own listener), and call the method to notify your user. window.showNotification('All Done')
So here's the tricky part, you've notified your user, but Vaadin has already sent the 'click' response back... so the Server part thinks it's notified the user, but it isn't able to show the user yet... You'll need a progress indicator on your page, as it asks the server every 5 seconds if anything has changed.
There are also some 'push' plugins, but I've found that most of the places that we we're spinning up threads, we want to show a 'loading' animation, so the progress indicator works well.
Not sure how to best explain this - If I use blocks to load images for UITableViewCells, how best can I ensure that when an image actually finishes loading - it is the correct image for the cell. Say I'm making an app with user icons - so cell 5 is for John and it starts loading John's image. Say that request gets hung up and by the time it returns, that cell has been reused for Bill at cell 23. We obviously don't want to load John's icon - we just want Bill's.
This is a simplified explanation. I know that we can check if a cell is visible in the block before setting the image - but say in a different scenario I have a method that makes a remote request when called. When the remote request is done, it calls a block defined in that method that updates the UI. If I call it and before it returns I call it again and only want the most recent call's block executed. Is there a good pattern for doing this?
Currently, I try to store a variable that has some state in the method so that when it returns I can check if that state is still valid. Just thought I'd see if there was a better way. Thanks.
Just checking if any updates on this.
So let's see if I can write a clear enough description of my problem...
I'm developing an application for a museum, where the user can find artworks either through an id or by scanning a qr tag...
Once either an id is entered or a tag scanned, the application sends the user from the search view, to the info view.
The info view gathers information about the artwork from an SQLite database...
My problem is, that in the info view, I call the function from the database class as such:
- (void)viewDidLoad
{
[super viewDidLoad];
NSArray *paintingInfo = [[PaintingDatabase database] findPaintingByID];
(additional code)
}
And I have no problem getting the info... works fine...
But my problem is, that if I go back to the search view and enter a new id or scan a new tag, the call/search isn't run again, since the view is still in memory...
So, how would I go about running
NSArray *paintingInfo = [[PaintingDatabase database] findPaintingByID];
every time I enter the view...?
I've tried placing it in viewDidAppear instead, but I get an EXC_BAD_ACCESS error...
I think you are close to answering your own question. Since viewDidLoad only gets called when your view loads, if you are using the same ViewController you will not get the results you are looking for. One option may be to destroy and create a new ViewController each time. This probably would be acceptable, performance-wise. Another option (that you seem to have explored) is to put your code in viewWillAppear. I would probably look into this more, and figure out what is causing your crash.
It's a bit difficult to tell from a brief description, but this feels to me like it's more of an application architecture issue than a problem with a specific bit of functionality.
You might be better off with an alternative approach, running the query from outside the info view, and then update the properties of the view through a delegate method. That's more of an MVC approach - the controller retrieves the data from the model, then passes the data over to the view to be displayed.
As you've described it, it seems like your info view is taking both view and controller functions - which could be why you're running into problems trying to get different data once the initial view is finished with.
The crash doesn't sound like a problem with the view, though - I'd second the advice to track that down and nail it as a separate issue.