Paul Clapham wrote:There's a concept called "N-and-a-half loop" which means that a loop will be executed N and a half times. This situation occurs when the loop looks like this:
It happens fairly often, and that's what Campbell has posted there. Only in the posted code, the "initialize" part is score = myScanner.nextInt() and the break-out test is score < 0. So the "initialize" and "break out" parts can be combined and put into the loop header.
But sometimes the "initialize" part is too complicated to do that and then the loop looks like this:
You don't see this very often, though, because there's somewhat of a prejudice against breaking out of the middle of a code block which dates back a couple of decades or so, back to when "structured programming" was the new big thing. So if the "initialize" part is too complex to roll into the loop header, people will make it into a method and then put that into the loop header.
Paul Clapham wrote:I put your code fragments into the "code" tags. Please do that in future so that it's easier to discuss code fragments. (Select the code fragment in your post and click on the "Code" button at the top of the box.)
Anyway: Look at line 3 in your second code fragment. Notice that you don't have the same thing in the first code fragment, so the two aren't equivalent.
Tim Moores wrote:It will not be the same Activity object, because Android does not know beforehand which activity will be called as the result of a startActivity call (that can change dynamically at runtime). This is easy to test by comparing the references of the different activity objects.
There are other circumstances under which an existing Activity object might get reused; the Activity Lifecycle documentation talks about that.
Norm Radder wrote:
will it be same Activity B object that got called previously or a new object
Why do you need to know that? I imagine the old object is collected and a new one created as needed.
Liutauras Vilda wrote:
Dreke Droga wrote:It's more than 5 attempts to get the success for easy program. What are the best methods to study and write successfully?
I won't be original here, but that's normal. Over the time you'll develop your senses what likely can go wrong in your so called "easy" programs and you'll be able to recognise those beforehand execution.
Other than that, you'll face problem solving failures in your career more often than you think. When you get more experience, you'll find yourself spending more time in planning and thinking about the problem, than you actually bang the keyboard. That will reduce surprises along the way, but won't eliminate unforeseen issues completely. The key would be, that you'd allocate some buffer for those.
Junilu Lacar wrote:If you're going to be a programmer, you'll need to get used to failure. Programmers, even experienced ones, hardly ever avoid bugs. In fact, there's one style of development where you intentionally start with a failure. To people who develop programs this way, failure is nothing more than a convenient way to detect that there's more to be done to make the program work properly. If you can turn around and use failures to your advantage, then you'll have a much better experience as a programmer.