EPTThe Big Programming Thread - Page 959
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
WarSame
Canada1950 Posts
| ||
|
berated-
United States1134 Posts
On May 15 2018 13:16 WarSame wrote: I have a task in my Android app that needs to run asynchronously. It contributes to the UI and requires context(needs an object from the Application). Do I use an AsyncTask, Fragment, or something else? I personally always thought the fragment thing was a hack. We ultimately use loaders for this type of stuff, but async task can work. You just need to make sure that when the async task runs on the main thread that you realize the activity that started it could be destroyed. Disclaimer most this information is from Android 2 years ago, don't know if they have new options but that looks like the same stuff. | ||
|
Acrofales
Spain18336 Posts
On May 15 2018 20:06 berated- wrote: I personally always thought the fragment thing was a hack. We ultimately use loaders for this type of stuff, but async task can work. You just need to make sure that when the async task runs on the main thread that you realize the activity that started it could be destroyed. Disclaimer most this information is from Android 2 years ago, don't know if they have new options but that looks like the same stuff. Doing UI stuff from asynctasks is a bit finicky. You need to use a Handler, and ensure the UI element you want to manipulate still exists (and the activity that called it is still there). However, it is one of the better ways in Android for short little things. If what you want is something persistent, you should probably use an intentservice or a futuretask (interaction with the UI is similarly finicky or even more so). Fragment has the advantage that it is a UI element, so changing the UI is easy. However, doing computation on the UI thread is a terrible idea, and if you want to run stuff asynchronously, Fragments are not the place for it: they will block the UI, and cause your app to stall/crash/get killed. | ||
|
WarSame
Canada1950 Posts
I tried it as an AsyncTask, too, and that seemed to work fine but I was wondering if there was a "better" Android way to do it. From what I've read and experienced it seems hard to pass data back from an IntentService to a particular Activity. I've mostly been sending information to the user from them in Notifications. I'll look into FutureTask. | ||
|
Hanh
146 Posts
Then your flow is: - user performs a UI action like clicking on a button, - button is bound to a field in the model view, which gets a onClick callback - onClick dispatches the async workflow - UI thread continues so the user can do other stuff if needed - async workflow dispatcher picks up the task and starts executing it - as it progresses, the w/f may update the model or it could update the model only at the end - when the model updates, observers are notified and recompute their output - view model updates the view properties that changed - view refreshes Consider your modern car, when you press on the gas pedal (UI) you send a signal (dispatch) to the on board computer (model). The later decides how much gas it should send to the engine (model logic). A bunch of sensors read your speed, rpm, etc. (view model) and they turn these values into something that the dashboard displays (view) Old cars would directly couple the gas pedal with the carburetor and the dashboard have gauges directly hooked to the wheels and engine. It is a far simpler design but it doesn't allow for much 'smartness'. | ||
|
WarSame
Canada1950 Posts
| ||
|
Blisse
Canada3710 Posts
Use one Activity. Up to you about whether you want lots of Fragments or not. Don't use AsyncTask or Loaders or Handlers. Use LiveData which is part of the new Architecture Components. Here's a bunch of modern samples. https://github.com/googlesamples/android-architecture-components https://developer.android.com/topic/libraries/architecture/ For fun watch about more modern Android development: | ||
|
berated-
United States1134 Posts
On May 16 2018 16:18 Blisse wrote: Of course you can implement the Observer pattern, just write a class that gates access to the ORM. Use one Activity. Up to you about whether you want lots of Fragments or not. Don't use AsyncTask or Loaders or Handlers. Use LiveData which is part of the new Architecture Components. Here's a bunch of modern samples. https://github.com/googlesamples/android-architecture-components https://developer.android.com/topic/libraries/architecture/ For fun watch about more modern Android development: https://www.youtube.com/watch?v=IrMw7MEgADk When did all this stuff come out? I just skimmed it but it looks way nicer than the previous apis. We abandoned the Android part after about a year of iterating to loaders for everything if you don't want your app to a crash and just use a webview wrapper for everything. Does the new architecture help handle network failures more easily too? | ||
|
Manit0u
Poland17776 Posts
![[image loading]](http://asset-f.soupcdn.com/asset/14140/7942_f819_960.png) | ||
|
Khalum
Austria831 Posts
On May 18 2018 03:28 Manit0u wrote: Seems rhobust. | ||
|
WarSame
Canada1950 Posts
On May 16 2018 16:18 Blisse wrote: Of course you can implement the Observer pattern, just write a class that gates access to the ORM. Use one Activity. Up to you about whether you want lots of Fragments or not. Don't use AsyncTask or Loaders or Handlers. Use LiveData which is part of the new Architecture Components. Here's a bunch of modern samples. https://github.com/googlesamples/android-architecture-components https://developer.android.com/topic/libraries/architecture/ For fun watch about more modern Android development: https://www.youtube.com/watch?v=IrMw7MEgADk Well, also because I don't think it applies to part of my use case. Generating a wallet file takes ~5s, which may be too long for a user to wait on an activity to get the updated data. However, I will do it because it seems better. | ||
|
Hanh
146 Posts
On May 18 2018 08:30 WarSame wrote: Well, also because I don't think it applies to part of my use case. Generating a wallet file takes ~5s, which may be too long for a user to wait on an activity to get the updated data. However, I will do it because it seems better. The user doesn't wait for anything. As I said, the workflow is async and the user interface is not blocked. If your app supports multiple wallets, he could even create more than one and still not block. | ||
|
WarSame
Canada1950 Posts
| ||
|
enigmaticcam
United States280 Posts
I have an entity and any user can potentially create a new row in that table. This table has an IsComplete field. I only want to allow creating new rows if all rows in the table are marked true for IsComplete. The default value when creating a new row is false for IsComplete. So obviously there's potential risk if two different people create a new row at the same time. In that scenario, I would only want one to be successful, and the other should fail because the first one is not complete. Typically I would just wrap the check and the save in a sql transaction script, but I'm not sure how to do that using EF. Any help? I tried googling, but I keep getting more broad information on just transactions or rolling back SaveChanges. | ||
|
Manit0u
Poland17776 Posts
| ||
|
supereddie
Netherlands151 Posts
On May 19 2018 02:43 enigmaticcam wrote: Question on entity framework in C#.Net. I know EF supports transactions. But I want my SaveChanges to be dependent on a database check and I'm not sure how to do that. I have an entity and any user can potentially create a new row in that table. This table has an IsComplete field. I only want to allow creating new rows if all rows in the table are marked true for IsComplete. The default value when creating a new row is false for IsComplete. So obviously there's potential risk if two different people create a new row at the same time. In that scenario, I would only want one to be successful, and the other should fail because the first one is not complete. Typically I would just wrap the check and the save in a sql transaction script, but I'm not sure how to do that using EF. Any help? I tried googling, but I keep getting more broad information on just transactions or rolling back SaveChanges. Just add a check constraint in the database. It will generate an exception and then you can rollback your transaction. | ||
|
sabas123
Netherlands3122 Posts
| ||
|
bo1b
Australia12814 Posts
On May 20 2018 00:43 sabas123 wrote: Just got my necessary math certificate after first hearing I failed it. Now I can finally go on to a University and study actual computer science instead of some flaky applied version. I'M SO HAPPY!!!! Good shit man  Depending on what you want to study in cs, selecting to do more mathematics rather then less can be a truly excellent idea. | ||
|
ShoCkeyy
7815 Posts
| ||
|
bo1b
Australia12814 Posts
| ||
| ||
