Yes, as it says in the summary, they take photos. And they do it with the data cable plugged in, so presumably they can force the phone display to change, and check that the screen image looks right.
They'll accept the machine whatever condition it is in, but the value will be less if it's damaged.
What happens if my phone is stolen and someone tries to cash it in? ecoATM kiosks have a variety of features in place specifically to deter stolen phones from entering our system. These features include the ability to capture; Drivers License or Govt ID Credit card Digital signature Fingerprint Picture / Video of consumer via webcam Address & email Date & location of transaction Details of what was collected, including the serial number ecoATM kiosks are also capable of refusing to transact any phones found in the databases that tract reported stolen phones.
Presumably which ones are actually used will vary from country to country and according to the agreement with the retailer who hosts the unit.
I'm sure the determined thief can find their way around these. But then they can already sell to a pawn broker or on ebay. A few of the dumber criminals might get caught.
The VCR/TV combos that I saw were always portable TVs. I quite often saw them in office environments, where they could be moved to where ever training or a presentation required them. In such a case, a separate TV and VCR wasn't a good option, because of having to carry 2 items, and the hassle of rewiring them together each time they were moved. And they probably had a useful life of, what 10-15 years?
For large screen TVs, building a VCR in wasn't very common. I imagine there was such a product but I never saw one.
Is it the long list or the long words that are impressing you most? Perhaps you'll be less impressed when you find out that all these "evaluate", "recommend", and "demonstrate"s all come down to answering a multiple choice question.
You are absolutely correct. Looking at the article from 2005, when she'd got the certification - the only apps she'd programmed were a calculator app and an app that sorted numbers.
The certification is worthless, and doesn't indicate any sort of prodigy.
She got Microsoft Professional Developer certification. But what has she actually developed? A calculator app and a sorting app. That's not so impressive even for a 9 year old.
The story here is that Microsoft Professional Developer certification is worth next to nothing.
Technically printf is a variadic function, not one which takes a void pointer.
Different issues. The variable number of parameters can also cause run time errors. But those variable number of parameters are all void*, as I said implicitly.
Using void pointers is a choice.
As is using ids.
C# and Java can do this. Not really sure what you're getting at to be honest...
It's not complicated. You pointed out a particular thing that you think C++ does better. I pointed out it's not different in that respect and picked out another topic in which Obj-C is better. You can't compare A and B if you only ever look at ways that A is better than B. You can also have to consider ways that B is better than A.
They're putting water in and taking steam out. The salt is going to be left in the ground. And given there's a shortage of cracks and fissures down there already, that doesn't sound like a good thing.
Yes, you can choose to use void pointers and subvert the type system if you so wish. That's a pretty dumb choice though and you deserve everything you get if your programs end up error prone. Obj-C's id type is an integral and unavoidable part of the language. Comparing the two things is a bit silly I think.
Both id and void* are part of the language. Both are avoidable. But of course we end up using them if the library uses them.
With Obj-C you end up using id when you use Apple's Foundation library collection classes.
With C++ you are using them with printf. The first parameter is a char*, and then you implicitly have an unlimited number of void* parameters. And if you get the type wrong, they'll only fail at run time.
I suppose there's a difference there in that C++ have templates, and that helps avoid void*. But then we're getting into features that one languages has that the other doesn't. Obj-C for example has categories, which allow you to extend the functionality of a library class - even if you don't have the source for it. C++ can't do that. It can only subclass. Which doesn't help if someone else's code is creating the class in the first place.
And on that note, it really shouldn't be called "Objective-C" but rather "Apple's bastardized take on Objective-C."
Ever tried to port code written for Mac OS X to GNUstep? You'll rapidly discover that the Objective-C that GCC uses isn't the Objective-C that Apple pulled from their ass.
That's kind of like blaming Microsoft because WINE only runs some WIndows apps.
Named parameters is more Python than C. And when you look at Obj-C code the named parameters (along with the square brackets surrounding them) are the most apparent features.
Google Analytics is basically a web tool. It can be used for Android apps, but it's not going to do the job as well as the purpose made Flurry Analytics. It doesn't have the ability to collect nearly as much information as Flurry.
*If* most Android developers are using Google Analytics, they're stupid. I suspect they're not that stupid, and your assertion is wrong.
Like any other bubble right now, iPhone apps will plummet in value and the disgusting amount of money invested in making apps that nobody wants based on horrible ideas will dry up, leaving a large swath of unemployable idiots paying the price. Of course those of us who what the hell we are doing will be fine. It happened after the.com crash, it will again soon with mobile apps.
"apps that nobody wants"? That's a strange use of the word "nobody" given that there have been 20 billion downloads from the Apple App Store.
That's Billion. 20,000,000,000. Count 'em.
I wish I had a dollar for every prediction that Apple product X is a fad. Even if I had to pay back 10 dollars for every such prediction that was right, I'd still have made a fortune.
But wait... you're not just predicting the downfall of iPhone apps but all mobile apps. As if somehow, all of a sudden, people will decide that they don't need computing, information or entertainment whilst on the move.
Let me guess... you're a web developer with sour grapes because your field isn't the big new thing any more.
What I am saying is that having a strong type system makes you more likely to catch the failures at compile time. The hypothetical you've just stated would require an explicit reinterpret_cast to get a foo pointer to point to a bar i.e. you're asking the compiler not to point out your mistake.
Not necessarily. id is what makes Obj-C somewhat weakly typed. But C++ has void* which has less type information than id does.
Out of interest how would you rank LLVM Obj-C against LLVM C++?
I couldn't say. I used to do C++ with GCC, then Obj-C with GCC, now Obj-C with LLVM. I think most people are still using GC for C++.
I'm kind of coming out of this sounding like a C++ apologist; I'm really not. Objective-C is not the answer though. It smells of the 80s.
For sure, they both smell of the 80s. Obj-C is far from perfect. But it's much nicer than C++.
Yes, UI is Cocoa (touch), and Cocoa is all Obj-C. As is Foundation.
The other exceptions for non-Obj-C UIs besides OpenGL is Carbon, which is C.
But outside of Cocoa and Foundation much most APIs are C. Core Foundation, Core Graphics, Core Animation, Core Audio. Grand Central Dispatch, all the Posix stuff, etc.
Yes, in practice every app other than OpenGL apps will need the UI doing with Obj-C APIs. I was just picking up on incorrect statement "all iOS APIs are Obj-C" really.
In case you haven't noticed, buggy C programs will fail at runtime just as much as buggy Obj-C programs. You treat a pointer to foo as if it's a pointer to unrelated class bar, it'll fail more often at runtime in C++ than in Obj-C.
What I think you meant is that the C++ compiler will catch more programmer errors at compile time than Obj-C the compiler will. But with the standard Obj-C compiler front end being LLVM now, the reverse is true. LLVM Obj-C compiler will catch far more programmer errors than the standard GCC C++ compiler.
On top of this, Obj-C allows techniques such as introspection that are just not available on C++.
It doesn't claim to measure actual usage. Indeed they explicitly point out that's not what they are measuring. So your expectation is bogus, not the metric. The metric is exactly what they say it is.
Slashdot Mirror
They sell them on auction sites, in whatever part of the world they'll have the highest value.
If they're broken or worthless for resale as phones, they sell them to recyclers who extract the gold and other precious materials in them.
Yes, as it says in the summary, they take photos. And they do it with the data cable plugged in, so presumably they can force the phone display to change, and check that the screen image looks right.
They'll accept the machine whatever condition it is in, but the value will be less if it's damaged.
Yea! Profit! Given that if was almost certainly free* when you got it.
(*Free with a contract.)
From their FAQ:
What happens if my phone is stolen and someone tries to cash it in?
ecoATM kiosks have a variety of features in place specifically to deter stolen phones from entering our system. These features include the ability to capture;
Drivers License or Govt ID
Credit card
Digital signature
Fingerprint
Picture / Video of consumer via webcam
Address & email
Date & location of transaction
Details of what was collected, including the serial number
ecoATM kiosks are also capable of refusing to transact any phones found in the databases that tract reported stolen phones.
Presumably which ones are actually used will vary from country to country and according to the agreement with the retailer who hosts the unit.
I'm sure the determined thief can find their way around these. But then they can already sell to a pawn broker or on ebay. A few of the dumber criminals might get caught.
The VCR/TV combos that I saw were always portable TVs. I quite often saw them in office environments, where they could be moved to where ever training or a presentation required them. In such a case, a separate TV and VCR wasn't a good option, because of having to carry 2 items, and the hassle of rewiring them together each time they were moved. And they probably had a useful life of, what 10-15 years?
For large screen TVs, building a VCR in wasn't very common. I imagine there was such a product but I never saw one.
Is it the long list or the long words that are impressing you most? Perhaps you'll be less impressed when you find out that all these "evaluate", "recommend", and "demonstrate"s all come down to answering a multiple choice question.
http://www.seattlepi.com/business/article/In-smarts-she-s-a-perfect-10-1178306.php#page-2
Why not?
http://www.youtube.com/watch?v=6nj2NjysOMI
You are absolutely correct. Looking at the article from 2005, when she'd got the certification - the only apps she'd programmed were a calculator app and an app that sorted numbers.
The certification is worthless, and doesn't indicate any sort of prodigy.
She got Microsoft Professional Developer certification. But what has she actually developed? A calculator app and a sorting app. That's not so impressive even for a 9 year old.
The story here is that Microsoft Professional Developer certification is worth next to nothing.
Technically printf is a variadic function, not one which takes a void pointer.
Different issues. The variable number of parameters can also cause run time errors. But those variable number of parameters are all void*, as I said implicitly.
Using void pointers is a choice.
As is using ids.
C# and Java can do this. Not really sure what you're getting at to be honest...
It's not complicated. You pointed out a particular thing that you think C++ does better. I pointed out it's not different in that respect and picked out another topic in which Obj-C is better. You can't compare A and B if you only ever look at ways that A is better than B. You can also have to consider ways that B is better than A.
Can I be the first to say: I don't care.
They're putting water in and taking steam out. The salt is going to be left in the ground. And given there's a shortage of cracks and fissures down there already, that doesn't sound like a good thing.
Yes, you can choose to use void pointers and subvert the type system if you so wish. That's a pretty dumb choice though and you deserve everything you get if your programs end up error prone. Obj-C's id type is an integral and unavoidable part of the language. Comparing the two things is a bit silly I think.
Both id and void* are part of the language. Both are avoidable. But of course we end up using them if the library uses them.
With Obj-C you end up using id when you use Apple's Foundation library collection classes.
With C++ you are using them with printf. The first parameter is a char*, and then you implicitly have an unlimited number of void* parameters. And if you get the type wrong, they'll only fail at run time.
I suppose there's a difference there in that C++ have templates, and that helps avoid void*. But then we're getting into features that one languages has that the other doesn't. Obj-C for example has categories, which allow you to extend the functionality of a library class - even if you don't have the source for it. C++ can't do that. It can only subclass. Which doesn't help if someone else's code is creating the class in the first place.
And on that note, it really shouldn't be called "Objective-C" but rather "Apple's bastardized take on Objective-C."
Ever tried to port code written for Mac OS X to GNUstep? You'll rapidly discover that the Objective-C that GCC uses isn't the Objective-C that Apple pulled from their ass.
That's kind of like blaming Microsoft because WINE only runs some WIndows apps.
If you like programming in Objective-C, then you're going to tend to pick an Apple platform to program on and for, rather than Linux.
If you like Objective-C why would you chose anything other than Apple's platforms to code for?
Named parameters is more Python than C. And when you look at Obj-C code the named parameters (along with the square brackets surrounding them) are the most apparent features.
... because the opinion of someone on a web forum 10 years ago is obviously definitive.
Google Analytics is basically a web tool. It can be used for Android apps, but it's not going to do the job as well as the purpose made Flurry Analytics. It doesn't have the ability to collect nearly as much information as Flurry.
*If* most Android developers are using Google Analytics, they're stupid. I suspect they're not that stupid, and your assertion is wrong.
Like any other bubble right now, iPhone apps will plummet in value and the disgusting amount of money invested in making apps that nobody wants based on horrible ideas will dry up, leaving a large swath of unemployable idiots paying the price. Of course those of us who what the hell we are doing will be fine. It happened after the .com crash, it will again soon with mobile apps.
"apps that nobody wants"? That's a strange use of the word "nobody" given that there have been 20 billion downloads from the Apple App Store.
That's Billion. 20,000,000,000. Count 'em.
I wish I had a dollar for every prediction that Apple product X is a fad. Even if I had to pay back 10 dollars for every such prediction that was right, I'd still have made a fortune.
But wait... you're not just predicting the downfall of iPhone apps but all mobile apps. As if somehow, all of a sudden, people will decide that they don't need computing, information or entertainment whilst on the move.
Let me guess... you're a web developer with sour grapes because your field isn't the big new thing any more.
What I am saying is that having a strong type system makes you more likely to catch the failures at compile time. The hypothetical you've just stated would require an explicit reinterpret_cast to get a foo pointer to point to a bar i.e. you're asking the compiler not to point out your mistake.
Not necessarily. id is what makes Obj-C somewhat weakly typed. But C++ has void* which has less type information than id does.
Out of interest how would you rank LLVM Obj-C against LLVM C++?
I couldn't say. I used to do C++ with GCC, then Obj-C with GCC, now Obj-C with LLVM. I think most people are still using GC for C++.
I'm kind of coming out of this sounding like a C++ apologist; I'm really not. Objective-C is not the answer though. It smells of the 80s.
For sure, they both smell of the 80s. Obj-C is far from perfect. But it's much nicer than C++.
Yes, UI is Cocoa (touch), and Cocoa is all Obj-C. As is Foundation.
The other exceptions for non-Obj-C UIs besides OpenGL is Carbon, which is C.
But outside of Cocoa and Foundation much most APIs are C. Core Foundation, Core Graphics, Core Animation, Core Audio. Grand Central Dispatch, all the Posix stuff, etc.
Yes, in practice every app other than OpenGL apps will need the UI doing with Obj-C APIs. I was just picking up on incorrect statement "all iOS APIs are Obj-C" really.
In case you haven't noticed, buggy C programs will fail at runtime just as much as buggy Obj-C programs. You treat a pointer to foo as if it's a pointer to unrelated class bar, it'll fail more often at runtime in C++ than in Obj-C.
What I think you meant is that the C++ compiler will catch more programmer errors at compile time than Obj-C the compiler will. But with the standard Obj-C compiler front end being LLVM now, the reverse is true. LLVM Obj-C compiler will catch far more programmer errors than the standard GCC C++ compiler.
On top of this, Obj-C allows techniques such as introspection that are just not available on C++.
It doesn't claim to measure actual usage. Indeed they explicitly point out that's not what they are measuring. So your expectation is bogus, not the metric. The metric is exactly what they say it is.