Apple: 'niet storen'-bug wordt automatisch verholpen
De 'niet storen'-feature die in iOS 6 zit ingebakken zal na 7 januari weer als vanouds werken, zo heeft Apple beloofd. Na de jaarwisseling bleek dat de functionaliteit, die geluiden van binnenkomende notificaties uitzet, ook buiten de ingestelde tijd geluiden dempt.
Op de site van Apple is een verklaring gepubliceerd waarin het probleem met de 'niet storen'-feature wordt erkend. De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen. Volgens Apple zal de functie na 7 januari weer normaal werken. Tot die tijd wordt geadviseerd om handmatig 'niet storen' uit te zetten. Een verklaring voor de bug werd niet gegeven.
De problemen met 'niet storen' verschenen na de jaarwisseling, toen gebruikers op verscheidene fora en sociale media lieten weten dat de functionaliteit zichzelf niet automatisch uitschakelde. De functionaliteit werd door Apple geïntroduceerd in iOS 6 en kan er bijvoorbeeld voor zorgen dat gebruikers 's nachts niet gestoord worden door geluiden van binnenkomende notificaties.
Het is niet de eerste keer dat iOS-software met problemen kampt na een jaarwisseling. Twee jaar geleden gebeurde dat ook al, toen bleek dat ingestelde wekkers niet langer functioneerden. Ook toen liet Apple weten dat de functionaliteit zichzelf zou herstellen, maar toch bleef een aantal gebruikers nog last hebben van de bug.
Reacties (75)
Jammer, want ik wordt liever met rust gelaten - meer van dat soort graag! 
Waarschijnlijk hebben ze te kampen met hetzelfde probleem als Microsoft in VisualBasic 6.0 / VBScript heeft zitten: http://support.microsoft.com/kb/200299
"When determining the week number of a date according to the ISO 8601 standard, the underlying function call to the Oleaut32.dll file mistakenly returns week 53 instead of week 1 for the last Monday in certain years."
"When determining the week number of a date according to the ISO 8601 standard, the underlying function call to the Oleaut32.dll file mistakenly returns week 53 instead of week 1 for the last Monday in certain years."
Hoeveel tweakers heb je nodig om een dag en tijd uit te rekenen? 
Als ik er als ontwikkelaar naar kijk constateer ik het volgende: Uitvinden wanneer een wekker af moet gaan of een timer aan of uit, behoort niet tot de categorie rakettechnologie. Toch is dit iets waar Apple wel heel vaak mee worstelt. Het jaar 2013 is geen bijzonder jaar. Het is geen schrikkeljaar. Het is geen priemgetal. Mijn wekker heeft nog nooit een dag overgeslagen. Mijn alarmsysteem met timers heeft nog nooit een timer moment gemist.
Mogelijke oorzaak 1: te weinig Separation Of Concern in iOS. Waarom moet de wekker uitzoeken hoe laat het is? De tijd wordt bepaald door de tijd service in het OS. Een timer service kan op afgesproken momenten een event af te laten gaan. De wekker zoekt dus niet uit hoe laat ie af moet gaan. De Do not disturb hoeft op de zelfde manier niet te bepalen hoe laat het is.
Mogelijke oorzaak 2: het OS zodanig een zooitje is dat ontwikkelaars niet meer weten welke calls ze moeten doen om uit te vinden hoe laat het is.
Mogelijke oorzaak 3: ontwikkelaars zijn met van alles bezig, maar niet de goede dingen. Managers kijken alleen of het er goed uitziet.
Alle mogelijke oorzaken zijn wat mij betreft even zorgelijk,
Als ik er als ontwikkelaar naar kijk constateer ik het volgende: Uitvinden wanneer een wekker af moet gaan of een timer aan of uit, behoort niet tot de categorie rakettechnologie. Toch is dit iets waar Apple wel heel vaak mee worstelt. Het jaar 2013 is geen bijzonder jaar. Het is geen schrikkeljaar. Het is geen priemgetal. Mijn wekker heeft nog nooit een dag overgeslagen. Mijn alarmsysteem met timers heeft nog nooit een timer moment gemist.
Mogelijke oorzaak 1: te weinig Separation Of Concern in iOS. Waarom moet de wekker uitzoeken hoe laat het is? De tijd wordt bepaald door de tijd service in het OS. Een timer service kan op afgesproken momenten een event af te laten gaan. De wekker zoekt dus niet uit hoe laat ie af moet gaan. De Do not disturb hoeft op de zelfde manier niet te bepalen hoe laat het is.
Mogelijke oorzaak 2: het OS zodanig een zooitje is dat ontwikkelaars niet meer weten welke calls ze moeten doen om uit te vinden hoe laat het is.
Mogelijke oorzaak 3: ontwikkelaars zijn met van alles bezig, maar niet de goede dingen. Managers kijken alleen of het er goed uitziet.
Alle mogelijke oorzaken zijn wat mij betreft even zorgelijk,
@TheWim: Mijns inziens is jouw houding exact waarom het zo vaak mis gaat met datum en tijd berekeningen. Mensen (en dus developers) denken ten onrechte dat het heel makkelijk is en maken dus allemaal fouten.
Als je denkt dat het makkelijk is kun je er donder op zeggen dat je code buggy is.
Er zijn legio voorbeelden van fouten met data en tijd, juist omdat het vol zit met complexe patronen, vreemde uitzonderingen, verschuivende tijdzones, zomer- en wintertijd veranderingen (zoek voor de lol eens op in welke tijdzone Arizona ligt) en obscure regels. Van het Y2K probleem tot Android die pasgeleden de hele maand december miste tot dit probleem. Het komt erg vaak voor.
Ik denk dat als je developers zou vragen om een stukje code te schrijven dat bepaalt of iets een schrikkeljaar is zonder dat ze informatie er over mogen opzoeken, 90% het fout doet. De meeste mensen denken dat ieder jaar deelbaar door 4 maar niet door 100 een schrikkeljaar is en gaan daarmee meteen de mist in.
Net als bij iets complex als cryptografie wordt er bij datum en tijd berekening altijd aangeraden zoveel mogelijk bestaande en beproefde libraries te gebruiken om bugs te vermijden.
Als je denkt dat het makkelijk is kun je er donder op zeggen dat je code buggy is.
Er zijn legio voorbeelden van fouten met data en tijd, juist omdat het vol zit met complexe patronen, vreemde uitzonderingen, verschuivende tijdzones, zomer- en wintertijd veranderingen (zoek voor de lol eens op in welke tijdzone Arizona ligt) en obscure regels. Van het Y2K probleem tot Android die pasgeleden de hele maand december miste tot dit probleem. Het komt erg vaak voor.
Ik denk dat als je developers zou vragen om een stukje code te schrijven dat bepaalt of iets een schrikkeljaar is zonder dat ze informatie er over mogen opzoeken, 90% het fout doet. De meeste mensen denken dat ieder jaar deelbaar door 4 maar niet door 100 een schrikkeljaar is en gaan daarmee meteen de mist in.
Net als bij iets complex als cryptografie wordt er bij datum en tijd berekening altijd aangeraden zoveel mogelijk bestaande en beproefde libraries te gebruiken om bugs te vermijden.
[Reactie gewijzigd door Maurits van Baerle op 3 januari 2013 12:38]
(en ook @jabwd) Zou kunnen, maar leg mij dan maar eens uit waarom de wekker geen last heeft van het probleem en de Do Not Disturb wel. Wat mij opviel is dat ze geen van beide last mogen hebben van de bug, of allebei wel. Blijkbaar is er een verschillende manier om tegen tijd/timers aan te kijken in beide applicaties. Hieruit trek ik mijn mogelijke conclusies.
Je hele reactie zit vol met conclusies die nergens op gebaseerd zijn. Je weet niet hoe de code er uit ziet, je weet niet hoe ze werken bij apple en je weet ook al helemaal niet hoe do not disturb werkt. Date & Time berekeningen zijn altijd lastig en fouten kunnen hier gewoon in kruipen, als jij hier nooit problemen mee hebt gehad is het heel erg goed mogelijk dat je code fout is en alleen werkt op bepaalde data ( wat vaak het geval is bij de meeste ontwikkelaars ), of de andere 'mogelijke oorzaak' dat je gewoon extreem onervaren bent. Als het nummer 86400 je bekent voor komt heb ik slecht nieuws voor je..
Er is een heel er goede reden waarom er zo verschrikkelijk veel API's beschikbaar zijn voor date & time, als het zo simpel was zou dat ook niet nodig zijn.
En natuurlijk neemt dit helemaal niet weg dat z'n fout niet echt moet gebeuren, maar bugs zijn er nou eenmaal en er staat zelfs een icoontje in je menubalk als do not disturb aan staat…
Er is een heel er goede reden waarom er zo verschrikkelijk veel API's beschikbaar zijn voor date & time, als het zo simpel was zou dat ook niet nodig zijn.
En natuurlijk neemt dit helemaal niet weg dat z'n fout niet echt moet gebeuren, maar bugs zijn er nou eenmaal en er staat zelfs een icoontje in je menubalk als do not disturb aan staat…
[Reactie gewijzigd door jabwd op 3 januari 2013 12:37]
Foutje moet kunnen, maar dat preserverende gedrag van Apple vind ik maar niets. Waarom kunnen ze de fout wel erkennen, maar niet uitleggen wat er mis gaat? Ze weten wat er is en dat het zichzelf oplost, maar kiezen ervoor geen uitleg te geven. Waarom moeten ze blijven doen alsof hun producten een soort magische wezentjes zijn? Ik heb nu bijvoorbeeld geen flauw idee of er een onzichtbare ongevraagde update gepusht wordt of dat het een probleem is dat zichzelf echt oplost.
Off topic: Leuk om de reacties hierover te lezen. Als persoon die niet professioneel in IT werkt heb ik weer wat bijgeleerd.
On topic:
Jammer wel dat Apple zo reageert. Ik begrijp (uit vorige posts) dat dit moeilijk en zinloos is om voor een zo korte tijd een bug fix te maken en dit uit te rollen. Maar dan zou ik PR gewijs dit niet melden. Door stomweg te zeggen 'wacht even, het lost zichzelf wel op'.
Dit is net hetgeen dat veel Apple gebruikers niet willen. Anders zouden ze niet voor het 'stabiele', altijd werkende Apple gaan (dit zijn de sterke punten die vaak aangehaald worden als ik me niet vergis).
Misschien beter zeggen dat je eraan werkt. . .
Als het zichzelf oplost weten de mensen toch niet of jij het nu was of niet.
(ITers natuurlijk wel omdat er geen patch was, maar de gemiddelde Apple gebruiker merkt niets)
On topic:
Jammer wel dat Apple zo reageert. Ik begrijp (uit vorige posts) dat dit moeilijk en zinloos is om voor een zo korte tijd een bug fix te maken en dit uit te rollen. Maar dan zou ik PR gewijs dit niet melden. Door stomweg te zeggen 'wacht even, het lost zichzelf wel op'.
Dit is net hetgeen dat veel Apple gebruikers niet willen. Anders zouden ze niet voor het 'stabiele', altijd werkende Apple gaan (dit zijn de sterke punten die vaak aangehaald worden als ik me niet vergis).
Misschien beter zeggen dat je eraan werkt. . .
Als het zichzelf oplost weten de mensen toch niet of jij het nu was of niet.
(ITers natuurlijk wel omdat er geen patch was, maar de gemiddelde Apple gebruiker merkt niets)
Wat willen Apple gebruikers dan? ik denk er weinig hierom wakker liggen.
Als het vanzelf oplost ... mooi klaar, vind al verbazend men hierover 69 berichten weten te plaatsen.
Als het vanzelf oplost ... mooi klaar, vind al verbazend men hierover 69 berichten weten te plaatsen.
Waarom is de oplossing; 'gewoon wachten', dan geen oplossing?
Dat is toch puur psychologisch dan?
Wat wil je dan? Een soort placebo patch op 6 januari waardoor men denkt dat er daadwerkelijk iets is gebeurd en het 7 januari opgelost is/lijkt?
Het ís zinloos (door allerlei verschillende redenen) om een patch te maken op deze korte termijn. Dus waarom niet gewoon toegeven; er zit een fout in, maar het is dan over.
Waarschijnlijk in de volgende iOS release notes staat netjes een fix vermeld zodat het volgend jaar niet weer gebeurd.
Ik, maar dat is dan misschien persoonlijk, vind het een bedrijf meer sieren om hier gewoon open en eerlijk over uit te komen dan angstvallig zeggen dat je er 'druk mee bent' terwijl er niets gebeurd.
Apple is inderdaad stabiel en werkend, en misschien wel meer stabiel en werkend dan Windows, of niet. Dat is waarschijnlijk een kwestie van smaak/mening. Maar omdat er eens een bugje in zit (en zeker van deze orde van grootte) is het niet ineens geheel onstabiel en niet meer betrouwbaar.
Als deze post aanvallend overkomt; dat was zeker niet de bedoeling
maar kon me toch niet helemaal vinden in jouw reactie.
Dat is toch puur psychologisch dan?
Wat wil je dan? Een soort placebo patch op 6 januari waardoor men denkt dat er daadwerkelijk iets is gebeurd en het 7 januari opgelost is/lijkt?
Het ís zinloos (door allerlei verschillende redenen) om een patch te maken op deze korte termijn. Dus waarom niet gewoon toegeven; er zit een fout in, maar het is dan over.
Waarschijnlijk in de volgende iOS release notes staat netjes een fix vermeld zodat het volgend jaar niet weer gebeurd.
Ik, maar dat is dan misschien persoonlijk, vind het een bedrijf meer sieren om hier gewoon open en eerlijk over uit te komen dan angstvallig zeggen dat je er 'druk mee bent' terwijl er niets gebeurd.
Apple is inderdaad stabiel en werkend, en misschien wel meer stabiel en werkend dan Windows, of niet. Dat is waarschijnlijk een kwestie van smaak/mening. Maar omdat er eens een bugje in zit (en zeker van deze orde van grootte) is het niet ineens geheel onstabiel en niet meer betrouwbaar.
Als deze post aanvallend overkomt; dat was zeker niet de bedoeling
maar kon me toch niet helemaal vinden in jouw reactie.
Toch maar rare manier van communiceren: wacht tot volgende week, dan is het probleem automatisch weg. In plaats van te zeggen dat ze hard aan het werken zijn om de problemen op te lossen en dat we een bugfix binnen de dag zullen ontvangen. Maar zover zijn we precies niet op de mobiele markt.
Ze zullen het onderzocht en gelokaliseerd hebben. Het lijkt er op dat ze daarbij hebben geconstateerd dat het uit zichzelf oplost op de 7e.
Zeer waarschijnlijk heeft het dus geen zin om een fix te ontwikkelen, te testen op de honderd meest voorkomende configuraties (je wil namelijk niet dat een fix nieuwe en mogelijk grotere problemen veroorzaakt), en dan over anderhalve week met een bugfix uit te komen nadat het zichzelf al heeft opgelost.
Het is volkomen logisch dat ze het zo oplossen. Het is hooguit raar dat ze niet bovenstaande uitleg (indien juist) communiceren.
Zeer waarschijnlijk heeft het dus geen zin om een fix te ontwikkelen, te testen op de honderd meest voorkomende configuraties (je wil namelijk niet dat een fix nieuwe en mogelijk grotere problemen veroorzaakt), en dan over anderhalve week met een bugfix uit te komen nadat het zichzelf al heeft opgelost.
Het is volkomen logisch dat ze het zo oplossen. Het is hooguit raar dat ze niet bovenstaande uitleg (indien juist) communiceren.
Daarvoor is de bug niet zwaar genoeg, het gaat hier niet om een security issue en het kan nog steeds manueel uitgeschakeld worden. Ik neem dus aan dat er wel grotere problemen zijn en de fix gewoon in 1 van de volgende updates wel zal zitten zodat hij niet opnieuw voorkomt.
Ik neem aan dat ze er dus wel degelijk aan werken, maar gezien de korte periode waarin het problemen geeft er geen haast achter steken. Moest het een blijvende bug zijn zou men dat wel doen.
Ik neem aan dat ze er dus wel degelijk aan werken, maar gezien de korte periode waarin het problemen geeft er geen haast achter steken. Moest het een blijvende bug zijn zou men dat wel doen.
Had het wel grappig gevonden als het na 21 December niet meer had gewerkt. 
Vreemdgenoeg is het probleem hier nu op mijn 2 apparaten (iPhone 4S en iPad 3) ook verholpen.
Wat ik daarentegen wel weer vreemd vind is het gedrag van beide apparaten:
Wat ik daarentegen wel weer vreemd vind is het gedrag van beide apparaten:
- iPhone 4S met iOS 6.0.1 › Op 1 januari én 2 januari een “hangende maan”
- iPad3 met iOS 6.0.1› Alléén op 2 januari een “hangende maan”
Meerdere nieuwsberichten over zo'n minuscule bug waar niet veel mensen heel veel hinder van zullen ondervinden, je kunt het immers met twee drukken op het scherm handmatig uitschakelen, net zoals de vliegtuigmodus dus.
Net zoals die blogs die nu met z'n allen melden dat de nieuwe iPhone verschillende kleuren krijgt omdat 1 of andere zelfbenoemde analist dit beweert.
Net zoals die blogs die nu met z'n allen melden dat de nieuwe iPhone verschillende kleuren krijgt omdat 1 of andere zelfbenoemde analist dit beweert.
Bij mij gaat de functie juist niet meer automatisch aan. Vanzelf uit gaat wel weer prima.
Wel beetje makkelijke weg zeg. Ondanks dat er een work-around schijnbaar is lijk me toch allerminst dat je zulke problemen oplost. Ik zag al inderdaad dat een aantal hier de datum naar 7 januari verplaatst dat die het niet meer doet. Probleem kan ik ongeveer weg gokken...deze week is week 53/week 01, bij oa opvragen via PHP met date("Y") krijg je 2012 ipv 2013. Door gebruik te maken van unix tijd date("o") krijg je wel de correcte jaar. Liep er vorige week tegenaan
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Overdrijven is ook een vak... Die bug is zo levensbedreigend en noodzakelijk dat jouw klanten geen 4 dagen zouden kunnen wachten? Hoelang denk je dat het duurt om een bugfix te maken, testen en distribueren aan miljoenen toestellen?Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Als mijn software draaide op miljoenen devices over de hele wereld, dan zouden mijn klanten het niet accepteren als ik overhaast een fix de deur uit doe, die onmogelijk binnen een week uitvoerig getest kan zijn.Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Als ze de bug hebben achterhaald, en hebben gezien dat het zichzelf oplost binnen een x aantal dagen, dan heeft het gewoon geen zin om een update te ontwikkelen, volledig te regressie-testen en uit te rollen, als die automatische oplossing toch eerder gaat zijn.
Het punt is dat niet 'alles' stuk is, maar een functie waar mensen prima zonder mee kunnen. Neemt niet weg dat het erg slordig is, en natuurlijk niet had mogen gebeuren. Maar goed, dates en programmatuur zijn altijd een apart verhaal, zou inderdaad goed te maken kunnen hebben met week 1.
Maar zo te zien is jouw bug server-side op te lossen en heeft dat geen betrekking op een fix verspreiden over miljoenen devices. Een proces dat waarschijnlijk net zo lang duurt als gewoon 4 dagen uitzitten.
Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou écht zo'n kritieke feature?
Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.
Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou écht zo'n kritieke feature?
Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.
[Reactie gewijzigd door jfversluis op 3 januari 2013 08:58]
De bug die ik benoem is inderdaad in mijn geval server side. Echter probeer ik voor mensen enigszinds te beschrijven wat er mis kan gaan. Uit eindelijk maakt het geen bal uit of ik nou op een server zit op een device, ze hebben allemaal dates...
Ik denk dat het niet aan mij is om het kritiek te beschouwen. Zelf heb ik geen iPhone dus kan er weinig over zeggen. Wat ik wel kritiek vind, al is het voor een paar dagen is:
De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen.
Stel je hebt een bedrijfstelefoon, en in het slechtste geval stond die voor een gehele dag in die stand (ingesteld), heb je dus de gehele dag geen telefoontjes of berichten die je hoort. Dat zou ik niet willen als ondernemer...zelfs niet als het iedere dag tussen een klein tijdsmoment is...
En inderdaad multinational met arrogante houding, worden ze uiteindelijk nog wel een keer op afgerekend.
Ik denk dat het niet aan mij is om het kritiek te beschouwen. Zelf heb ik geen iPhone dus kan er weinig over zeggen. Wat ik wel kritiek vind, al is het voor een paar dagen is:
De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen.
Stel je hebt een bedrijfstelefoon, en in het slechtste geval stond die voor een gehele dag in die stand (ingesteld), heb je dus de gehele dag geen telefoontjes of berichten die je hoort. Dat zou ik niet willen als ondernemer...zelfs niet als het iedere dag tussen een klein tijdsmoment is...
En inderdaad multinational met arrogante houding, worden ze uiteindelijk nog wel een keer op afgerekend.
Ik wil geen eindeloze discussie aanzwengelen, echter gaat het inderdaad om data. Dat maakt niet uit server-side of client-side, echter het uitrollen; de logistiek en (eventuele) impact hiervan is compleet verschillend.
Ik kan me dan goed voorstellen dat je de afweging maakt om je in dat proces te storten of mensen te adviseren even af te wachten en de functie een paar dagen uit te schakelen/handmatig te bedienen.
Als ondernemer zou ik je niet erg slim vinden als jij je telefoon overdag op de DnD stand zet dan is het nogal wiedes dat je dingen gaat missen. Daarnaast zijn er volgens mij maar weinig mensen die toch niet tussentijds even hun iPhone een keer aandrukken om te kijken of ze toch per ongeluk wat hebben gemist.
Daarboven op omhelst de functie ook nog een escape waarbij bepaalde contactpersonen altijd doorkomen en herhaaldelijke oproepen ook doorkomen. Ik kan me ook haast niet voorstellen dat veel mensen dat uitzetten. Met andere woorden; kritieke telefoontjes kun je haast niet missen.
Ik denk niet dat ze hier heel hard op worden afgerekend. Nogmaals; het is slordig, maar volgens mij niet kritiek en ik kan de afweging om gewoon af te wachten heel goed begrijpen.
Ik kan me dan goed voorstellen dat je de afweging maakt om je in dat proces te storten of mensen te adviseren even af te wachten en de functie een paar dagen uit te schakelen/handmatig te bedienen.
Als ondernemer zou ik je niet erg slim vinden als jij je telefoon overdag op de DnD stand zet
dan is het nogal wiedes dat je dingen gaat missen. Daarnaast zijn er volgens mij maar weinig mensen die toch niet tussentijds even hun iPhone een keer aandrukken om te kijken of ze toch per ongeluk wat hebben gemist.Daarboven op omhelst de functie ook nog een escape waarbij bepaalde contactpersonen altijd doorkomen en herhaaldelijke oproepen ook doorkomen. Ik kan me ook haast niet voorstellen dat veel mensen dat uitzetten. Met andere woorden; kritieke telefoontjes kun je haast niet missen.
Ik denk niet dat ze hier heel hard op worden afgerekend. Nogmaals; het is slordig, maar volgens mij niet kritiek en ik kan de afweging om gewoon af te wachten heel goed begrijpen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
