|
I had just taken a sip of water.
It's a miracle I didn't just spew it all over my keyboard.
|
|
|
|
|
Interesting.
How come there are no loading times when the screen is turned off and then turned on again? Is the phone always on even if the screen is turned off?
|
|
|
|
|
I believe the phone is always on, in daemon mode at least.
It has to perform at least the basic function of receiving a call even when the screen is dark, isn't it; and a caller can call anytime, (I mean switched on, except when in airplane mode or when switched off).
|
|
|
|
|
I think if you do a full shut down of your phone, it'll be pretty obvious that yes, the whole OS stays running when the screen is turned off.
Most PCs nowadays can do a full cold start faster than a phone can fully boot up.
I don't find apps to be loading particularly fast either, if you have the nasty habit of explicitly closing them down yourself.
|
|
|
|
|
If they change the programming languages the apps are made with does it mean they don’t worry about making legacy apps compatible with new OS versions?
|
|
|
|
|
Depends on the popularity of the app, and the financial strength of the developer. Perhaps a number of mobile apps have become extinct.
|
|
|
|
|
Pffft! They already don't care about compatibility. At least when it comes to Android. I have a major beef with this.
Weren't we promised X many years of support after endless complaints? It's still a joke to this day.
I have a number of Android tablets, running 2.2 (I believe), 4.2, 4.3, 6.0 and most recently, 13.0. Of these, only the one on 4.2 ever get an OS upgrade (from 4.1 -> 4.2).
When I realized that 6.0 was still going to be the same (it'll die with the same OS it was purchased with, with no chance of ever getting any sort of update), I told myself I was done with Android. Realistically, Android 6.0 is a non-starter in 2024. So like every fool out there, I finally broke down and bought yet another piece of hardware running 13.
My current phone's on Android 9. The most recent update for it goes back to September 2019. It never offered anything newer.
This annoys me to no end.
I have laptops that - seriously - are 20 years old, and could still run Windows 10 if I only bothered to install it. It would not be pretty, but it'd still work. At least that would be my decision.
|
|
|
|
|
I agree, and wanna add:
Many cross-platform apps are built in the Electron framework (JavaScript-based)
Well known Electron-apps across phones and desktops are
* Slack
* Spotify
* vs-Code
But I would bet that Farcebook et. cohortes are also Electron
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
|
An add on like that probably slows down things in an environment that so slim and rationalized
|
|
|
|
|
I never used it and never did any mobile development but my guess is that it is not the most optimal way to write Android apps, however if you want to stick to C# and do multi-platform development it might be of interest ...
|
|
|
|
|
I'm not a mobile dev, so take it with a grain of salt. But, there's:
Java (very popular on mobile)
React Native
Go
Swift for iOS
Objective C for iOS
Or just using web technology and making a PWA (Progressive Web App) that looks and feels like a native app.
I'm sure there are others, but those are some of the big players in the mobile world.
Jeremy Falcon
|
|
|
|
|
Embarcadero then and when 
|
|
|
|
|
|
For all my brothers and sisters that do unit test. How many unit tests do y'all have for say a typical sized project of say ~100 files?
For my personal smaller projects, I can easily have hundreds of tests. Like I got 45 tests just in one file alone I just wrote that has three utility routines in it. As the project grows that number can easily grow too.
For a typical enterprise worthy website or even a polished personal project, that number will easily be anywhere from 2-4K unit tests. Not to mention dozens of functional tests.
So, for those of you who embrace the awesome that is testing, how many you typically roll with?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: enterprise worthy website
I won't touch those, as you know.
I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
|
|
|
|
|
PIEBALDconsult wrote: I won't touch those, as you know.
Not sure I follow, you won't touch an enterprise website or unit tests?
PIEBALDconsult wrote: I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
That's why I limited the scope. Don't really need another "I don't like it because just don't like it but I can't admit that so I'll diss it" type posts. Just saying man, you'll never convince me unit testing isn't warranted in mission critical software. Some people will never do it because it takes more work and nothing I say is gonna make them change or put more effort into their work. Thus, the question was directed at those who do unit test.
Jeremy Falcon
|
|
|
|
|
I unit and integration test etc., of course, but not with a testing framework.
|
|
|
|
|
Well, sorry if I'm sounding jaded, but it's because I am. 
I've spent my life online arguing with peeps who do nothing but hate, argue, are just miserable, barely educated, arrogant, and have absolutely no experience with the topic being argued about, etc. Ironically, I've become miserable in the process of not liking miserable.
Not sure why you wouldn't use a framework though, but I'll just say cool so I'm not the antithesis of unit testing bashers.
Jeremy Falcon
|
|
|
|
|
I can understand that. Though I've never heard of anyone recommending against using testing frameworks.
I've definitely seen some with the attitude that if you're not using a unit testing framework then you're not testing at all, and that is simply a ridiculous point of view.
|
|
|
|
|
PIEBALDconsult wrote: Though I've never heard of anyone recommending against using testing frameworks.
There have been peeps that have, right here on CP even. Seems silly IMO.
PIEBALDconsult wrote: I've definitely seen some with the attitude that if you're not using a unit testing framework then you're not testing at all, and that is simply a ridiculous point of view.
Well, I'm trying not to turn this into a debate. There's 90% chance any post on CP will be derailed and turned into the same debate we've always had for years. It's just a simple question I asked and yet here we are again in endless debates saying the same thing over and over. It's a waste of time and energy when all I'm trying to do is ask peeps a number.
I will say though, there are different levels of testing: unit, functional, integration, regression, user acceptance, etc. And most devs I've talked to that don't unit test don't know the difference. Which makes it hard to trust how much they really know about testing. But, so many of the devs who have no clue will all pretend they know, but those who do know... know who's faking it.
For integration and user acceptance, I'd almost say there's credence to your position for a personal project. But for unit and functional you cannot be repeatably deterministic or automate the ability of code breaking from a rogue commit without it. I'll save regressions for another day, but those need to be automated too. Maybe regressions are overkill for a personal project, but definitely not in the enterprise.
Clearly we'll have to disagree. I'm not gonna convince you of anything and vice versa. But, out of the two of us, it sounds like I'm the only one with experience on the topic. So, I'm politely saying you are missing out.
Jeremy Falcon
|
|
|
|
|
Seems about right.
Never counted though, so I looked at a personal project of 100+ files: there are around 250 tests but most tests have multiple assertions, so I'd guess about 500 to 1000 conditions checked.
For me, the number of tests grows with time. Almost every bug turns into a test, first to identify it, than to make sure it's quashed.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: Never counted though, so I looked at a personal project of 100+ files: there are around 250 tests but most tests have multiple assertions, so I'd guess about 500 to 1000 conditions checked.
Oddly enough, despite me not being a math wizard, I'm a number's nerd. Gotta print them totals for the warm fuzzies. Glad to know my findings are on par with yours.
Mircea Neacsu wrote: For me, the number of tests grows with time. Almost every bug turns into a test, first to identify it, than to make sure it's quashed.
Tru dat man. Tru dat.
Jeremy Falcon
|
|
|
|
|
I don't, and I'm very well aware that I should.
But, the company I work for is small enough and the software I work on is typically so small scale (relatively speaking) that my boss wouldn't want me to start spending time working on something that is "not code that we ship and will make us money" (and that's pretty much a direct quote). Unless I started to regularly write stuff that produces questionable results.
I'm not gonna pretend I'm all that and a bag of chips, but my boss and coworkers know that when I'm comfortable enough to say something's done (by my own yardstick), it's generally in pretty good shape and it's rare someone will find any sort of major hole I didn't think of. If I wasn't likely to think of some scenario my code should support, I wouldn't be likely to think about writing a unit test for it anyway. Having said that, I fully realize this is where regression testing would really help ensure I don't forget about something when refactoring week or months after I wrote the code originally.
I'm not trying to disagree. If I was working on mission-critical software at a large corporation, I would insist I get to do it. I was just never presented with the circumstances where I could justify the extra time to my boss. From my perspective, it only needs to happen once.
|
|
|
|
|
Smaller companies generally don't have much leeway for anything. You might get more freedom at a company, in the sense there are no code reviews, etc. But, they don't have the money for much. That's the tradeoff.
What your boss is really saying is, he doesn't want you learning on the job because they don't want to pay for it. They don't know the value in something if you don't tell them. It's a small company - trust me... they don't know. If you learned something on your free time and came to him/her as an expert about the pros/cons it would be a different story.
I've been an employer, so I'm not making this up. Also, I've witnessed firsthand where stuff like this happened in a company where the CEO was worried about budget because this was their first time in the tech world (coming from cookie manufacturing).
And sure, lousy employers do exist. But, more times than not what is really going on is people lie about timelines and always take longer. Given that, some are tired of hearing anything that would cause more time. It's an endless cycle that never stops unless the devs start estimate honestly.
I could go on, but you get the idea. Nobody wants a worse product. Everyone loves initiative from learning something on your own time. It's an easy sell unless the company is almost broke. In which case, you should be looking for another job.
Jeremy Falcon
modified 3-Sep-24 14:45pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
